一次性讲清楚OAuth2.0认证(二）

上期我们聊了传统session认证和oatuh认证一些基本原理，接下来我们将详细了解oatuh的认证过程。

oAuth从1.0已经来到了2.0，OAuth 2.0定义了四种授权方式：

•  授权码模式（authorization code） 

• 简化模式（implicit） 

• 密码模式（resource owner password credentials） 

• 客户端模式（client credentials）

以知乎为例：

知乎首页登录页：

https://www.zhihu.com/signin?next=%2F

点击微信，跳转到一个URL：

https://open.weixin.qq.com/connect/qrconnect?appid=wx268fcfe924dcb171&redirect_uri=https://www.zhihu.com/oauth/callback/wechat?action=login&from=&response_type=code&scope=snsapi_login#wechat

（有的认证中会附件一个可选项state，State会有一个随机数，会存起来并发给知乎，（如图中的B）当确定授权后，微信会把这个随机数带上code的参数信息发给知乎，知乎检查有state，就认为是微信发的不是别人发的。防止crsf的攻击。是一个可选项。）

A步骤中，客户端申请认证的URI，包含以下参数：

• response_type：表示授权类型，必选项，此处的值固定为"code" 

• client_id：表示客户端的ID，必选项（上述案例中是APPID）

• redirect_uri：表示重定向URI，可选项（虽然可选，但是为了安全起见还行需要带上，可以明确让认证服务器发给指定的URL接收地址）

• scope：表示申请的权限范围，可选项 

• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

C步骤中，服务器回应客户端的URI，包含以下参数：

• code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和回调地址URI，是一一对应关系。

• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

D步骤中，客户端使用授权码向认证服务器申请令牌的HTTP请求，包含以下参数：

• grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。

• code：从上一步获得的授权码，必选项。 

• redirect_uri：表示回调地址URI，必选项，且必须与A步骤中的该参数值保持一致。

• client_id：表示客户端ID，必选项。

将 client_secret 明文包含在请求体中

将 client_id 和 client_secret 通过 Base64 编码后放在 Authorization 头中

公共客户端（Public Client，如移动应用或 SPA）通常不依赖 client_secret，而是通过 PKCE（Proof Key for Code Exchange） 增强安全性。（PKCE 的作用：在公共客户端中，通过动态生成的 code_verifier 和 code_challenge 替代 client_secret，防止授权码劫持攻击。）

E步骤中，认证服务器发送的HTTP响应，包含以下参数：

• access_token：表示访问令牌，必选项。

• token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。 

• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。 

• refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。 

• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤， v所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

（A）客户端将用户引导向认证服务器。客户端发出的HTTP请求，包含以下参数： 

• response_type：表示授权类型，此处的值固定为"token"，必选项。 

• client_id：表示客户端的ID，必选项。 

• redirect_uri：表示重定向的URI，可选项。 

• scope：表示权限范围，可选项。 

• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

（B）用户决定是否给于客户端授权。（点击微信授权）

（C）假设用户给予授权，认证服务器将用户引导向客户端指定的"回调地址URI"，并在URI的Hash部分包含了访问令牌。认证服务器回应客户端（知乎）的URI，包含以下参数： 

• access_token：表示访问令牌，必选项。 

• token_type：表示令牌类型，该值大小写不敏感，必选项。 

• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。 

• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。 

• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

（D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。 

（E）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。 

（F）浏览器执行上一步获得的脚本，提取出令牌。

（G）浏览器将令牌发给客户端。

注：简化模式在OAuth2.1中已经被废弃，这里各位同仁只做了解即可。

密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务提供商"索要授权。 在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。

A）用户向客户端提供用户名和密码。

（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。客户端发出的HTTP请求，包含以下参数：

• grant_type：表示授权类型，此处的值固定为"password"，必选项。 

• username：表示用户名，必选项。

• password：表示用户的密码，必选项。 

• scope：表示权限范围，可选项。

客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。

（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。客户端发出的HTTP请求，包含以下参数：

• grant_type：表示授权类型，此处的值固定为"client_credentials"，必选项。

• scope：表示权限范围，可选项。

（B）认证服务器确认无误后，向客户端提供访问令牌。

HTTP /1.1  200  OK Content-Type: application/json;charset=UTF-8Cache-Control: no-store Pragma: no-cache   {     "access_token":"2YotnFZFEjr1zCsicMWpAA",    "token_type":"example",    "expires_in":3600,    "example_parameter":"example_value"   } 

在上文中我们提到授权码 + PKCE 模式，这个是另一个扩展加强版安全保障模式，它可以防止恶意应用程序通过截获授权码和重定向 URI 来获得访问令牌。PKCE 通过将随机字符串（code_verifier）和其 SHA-256 哈希值（code_challenge）与授权请求一起发送，确保访问令牌只能由具有相应 code_verifier 的应用程序使用，保障用户的安全性。这个是一个复杂过程。详情请阅下期文章。我们专门介绍授权码 + PKCE 模式，以及OAuth认证有哪些安全性问题。