OAuth2.0-授权码模式解析

前言

OAuth 2.0是行业标准的授权协议。 OAuth 2.0取代了2006年创建的原始OAuth协议所做的工作。它专注于客户端开发人员的简单性，同时为Web应用程序，桌面应用程序，移动电话和客厅设备提供特定的授权流程。该规范及其扩展正在IETF OAuth工作组内开发。

授权码模式流程解析

在Oauth2.0授权码模式中会涉及以下几个角色，我们分别授予他们具体的场景解释：

Client：指应用程序（可以理解为任意支持微信登陆的程序，这里我们以熊猫TV为列）

Resource Owner：程序的用户（我是微信的用户）

Authorization Server：授权服务器（服务方微信的授权服务器）

Resource Server：资源服务器（服务方微信的资源服务器）

User-Agent：浏览器（用来跳转服务器微信开发的用户授权页面）

我们按照图中的流传递编号分析授权码模式的过程：

A：在应用程序中选择微信登陆，此时应用程序会请求用户授权登陆页面（这是微信的用户授权页面），在跳转的过程中

会打开浏览器并携带如下参数：

https://authorization-server.com/auth
 ?response_type=code
 &client_id=29352915982374239857
 &redirect_uri=https%3A%2F%2Fexample-app.com%2Fcallback
 &scope=create+delete
 &state=xcoiv98y2kd22vusuye3kch

• response_type：告诉授权服务器（微信）这是授权码模式
• clien_id：第三方应用程序（熊猫TV）的客户端标识符（client_id和client_secret等信息在熊猫TV向微信平台注册时会获得）
• redirect_uri：第三方应用程序的地址，告诉授权服务器（微信）在批准请求后应该将用户等信息返回的位置。（这个uri是应用程序自己配置的，微信授权完成后人家得知道授权结果该发到哪）
• scope：这是一个或多个空格分隔的字符串，指示第三方应用程序请求的权限。
• state：第三应用程序随机生成的字符串，state在传给授权服务器之后，授权服务器在授权完成后会将该state返回给第三方应用程序。第三方程序接收到授权服务器（微信）返回的state后会和当初发送的state进行对比判断两个值是否相等。（主要用户防防止CSRF攻击）

B：用户看到《用户授权页面》并选择【授权】或者【拒绝授权】

C：假设用户选择【授权】，并且第三方程序发送的请求参数都正确（A流中传递过来的参数）。授权服务器（微信）经过一系列校验后通过后会生成一个Authorization code（授权码）同时会通过redierct_uri返回如下参数：

https://example-app.com/redirect
 ?code=g0ZGZmNjVmOWIjNTk2NTk4ZTYyZGI3
 &state=xcoiv98y2kd22vusuye3kch

• state：第三方应用程序请求时发送的state，状态值与第三方应用程序最初在请求中设置的值相同。
• authorization code：授权服务器（微信）产生的code，它的有效期通常为1～10分钟。（有效期在授权服务器设置）

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------美丽的分割线，以下步骤将对用户不可见---------------------------------------------------------------------------------------------第三方程序收到authorization code会用其换取access_token--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

D：第三方应用程序已经接收到授权服务器产生的authorization code，并且校验返回的state和请求state的一致性，确认authorization code是当初发出的请求对应返回的授权码。确认无误后第三方应用程序会再次向授权服务器发送请求（这次是Post请求）。这次请求的目的是用authorization code换取access_token，请求的参数如下：

• grant_type：告诉token point第三方用户程序正在使用授权码模式
• authorization_code：从授权服务器（微信）获取到的授权码
• redirect_uri：和A步骤传递的值一样，同样是为了告诉授权服务器服务器在授权完成后将授权结果发送到哪（这个参数不是必须的，使用的时候需要仔细查看所调用的API是否要求了传递该参数）
• client_id：第三方应用程序的标识符
• client_secret：第三方应用程序的密钥（这是为了确保获取access_token的请求来自第三方应用程序，而不是来自某个劫取authorization code的危险者的请求）

E：授权服务器（微信）接收到请求并完成校验，通过后会想redirect_uri返回如下参数：

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
  "scope":"create delete"
}

本文分析了Oauth2.0授权码模式的原理和流传递间的参数，在阅读过程中如果您有任何疑问和建议欢迎留言探讨。

参考文献：

https://tools.ietf.org/html/rfc6749 

https://developer.okta.com/blog/2018/04/10/oauth-authorization-code-grant-type