OAuth 2.0设计（以微信登录为例）

在实际应用开发中，我们常常需要使用微信作为应用的登陆方式，不同于手Q登陆使用传统的ptlogin，微信登陆采用了OAuth 2.0的验证方式。本文将以微信登录为案例，具体分析介绍所采用的OAuth 2.0验证方式。

1. 场景介绍。

作为一个第三方应用，用户通过微信登录应用，应用方想获取用户的一些私密信息，如微信头像和微信昵称等。此时，有两种不同的开发方案：

• 方案1：用户在第三方应用输入微信号和密码，应用方直接通过微信号和密码向微信服务器请求具体的信息。（显然是不现实的，微信也不会允许）
• 方案2：通过OAuth 2.0验证方案，在第三方应用不知道用户密码甚至微信账号信息的情况下获取需要的信息。

2. 什么是OAuth 2.0？

直白点说，OAuth 2.0是个授权框架。它定义了第三方应用如何通过用户授权，来访问用户的受限资源。允许用户让第三方应用访问该用户在某服务的特定私有资源但是不提供账号密码信息给第三方应用。

OAuth 2.0中O代表的是Open，开放；Auth代表的是Authenticate和Authorize，即验证和授权。涉及到的关键参与方有以下四个：

• resource owner：对应着OAuth 1.0中的 User 角色，授权过程中的主体。
• client：对应着OAuth 1.0中Consumer 的概念，通过申请获得resource owner的授权，从而实现访问受保护资源的第三方的软件或者服务，是授权过程中的客体。
• resource server ：存储着resource owner的受保护资源的服务器，可以通过验证access token来开放对resource owner的数据的访问。
• authorization server：在resource owner授权完毕后，负责颁发access token 的服务器。（实际项目中，resource server和authorization server可能部署在一台服务器上，甚至根本就是一套服务进程。）
  
  （A）：客户端请求资源所有者的授权。
  （B）：资源所有者同意授权。
  （C）：客户端获得了资源所有者的授权之后，向授权服务器申请授权令牌。
  （D）：授权服务器验证客户端无误后发放授权令牌。
  （E）：客户端拿到授权令牌之后请求资源服务器发送用户信息。
  （F）：资源服务器验证令牌无误后将用户信息发放给客户端。

其中获得用户授权是重点，业界目前一共有四种授权方式：

• 授权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 用户端模式（client credentials）

3. 授权码模式介绍。

本文将主要介绍最常见使用的授权码模式，具体流程如下所示：

A、B 步骤用户使用第三方应用请求授权：第三方应用将资源所有者导向一个特定的地址，附带以下请求信息：

• response_type：必选，请求类型。这里固定为"code"。
• client_id：必选，标识第三方应用的id。很多地方也用apppid来代替。
• redirect_uri：可选，授权完成后重定向的地址。当取得用户授权后，服务将重定向到这个地址，并在地址里附带上授权码。
• scope：可选，第三方请求的资源范围。比如是想获取基本信息、敏感信息等。
• state：推荐，用于状态保持，可以是任意字符串。授权服务会原封不动地返回。

C步骤，第三方应用拿到授权请求的response：资源所有者同意授权第三方应用访问受限资源后，请求返回，跳转到 redirect_uri 指定的地址。返回body有：

• code：必选，授权码。后续步骤中，用来交换access token。
• state：必选（如果授权请求中，带上了state），这里原封不动地回传。

D步骤，第三方应用继续请求access token：第三方应用向授权服务请求获取access token。请求参数包括：

• grant_type：必选，许可类型，这里固定为“authorization_code”。
• code：必选，授权码。在用户授权步骤中，授权服务返回的。
• redirect_uri：必选，如果在授权请求步骤中，带上了redirect_uri，那么这里也必须带上，且值相同。
• client_id：必选，第三方应用id。

E步骤，授权服务返回给第三方应用access token：请求合法且授权验证通过，那么授权服务将access token返回给第三方应用。返回body有：

• access token：访问令牌，第三方应用访问用户资源的凭证。
• access_token_expires_in：access token的有效时长。
• refresh token：更新access token的凭证。当access token过期，可以refresh token为凭证，获取新的access token。
• refresh_token_expires_in：refresh token的有效时长。

4. 授权码模式具体到微信登录架构设计。

授权码模式具体到微信应用如下所示：

应用登录请求步骤和携带参数：

A，B --> 用户请求授权：请求带上appid、redirect_uri、response_type、scope、state。其中：

• appid：应用id，就是前面提到的client_id。
• redirect_uri：授权回调的地址，在微信管理后台填写。
• response_type：响应类型，固定为"code"。
• scope：授权许可范围，固定为"snsapi_login"。
• state：可选，授权服务回传。

C --> 用户同意授权，重定向到 redirect_uri， 并返回临时票据code。如下所示：

D --> 应用拿到code，用code去获取 access token。携带参数如下：
appid：必选，应用id。

• secret：必选，应用秘钥，在微信后台生成。
• code：必选，前面获取的授权码。
• grant_type：必选，值固定为"authorization_code"

https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code

E --> 微信后台验证，确认请求合法后，将access token返回给第三方应用。

access_token是调用授权关系接口的凭证，由于access_token有效期（目前为2小时）较短，当access_token超时后，可以用refresh_token进行刷新，access_token刷新结果有两种：

• 若access_token已超时，那么进行refresh_token会获取一个新的access_token，新的超时时间；
• 若access_token未超时，那么进行refresh_token不会改变access_token，但超时时间会刷新，相当于续期access_token。
• refresh_token拥有较长的有效期（30天），当refresh_token失效的后，则引导用户重新授权获取新的refresh_token。

5. OAuth 2.0为什么不直接返回access_token?

问题：OAuth 2.0为什么不直接返回access_token?要设定为返回auth_code之后再去请求accessToken？

主要出于安全方考虑，防止中间人攻击。假设第三方应用、授权服务不直接通信，中间隔了一层代理。且第三方应用采用HTTP协议，这样恶意代理就能窃取access token。因此，采用了通过code来交换access token的方式，来增加安全性。并且不能将access token直接给到用户侧，相对于用户侧网络环境的复杂性，第三方应用自身服务端的网络环境相对更安全。

特别注意：对于授权码和access_token的篡改，在OAuth 1.0中是反复的对Code和Token进行签名，来保证Token不会被篡改，但是OAuth 2.0中却没有，因为OAuth 2.0是基于Https的，所以如果没有Https的支持OAuth 2.0可能还不如OAuth 1.0。在 OAuth 2.0 中，使用 HTTPS 可以说是必须的，而且 client 有义务验证证书的真假，防止中间人攻击，而 authorization server 和 resource server 都有义务申请可信任的第三方颁发的真实的 SSL 证书。

本文参考文献：
OAuth 2.0规范：https://tools.ietf.org/html/rfc6749
微信授权资料：https://developers.weixin.qq.com/doc/oplatform/Website_App/
WeChat_Login/Wechat_Login.html

我是pavel，一位憨憨傻傻的程序员，平时幽默又有才，专注于Java，go，微服务，云开发。不定时发送些鹅厂程序员的工作/生活日常，请大家多多关注我的公众号！