OAuth2.0协议(一) - 授权码许可流程

OAuth2.0是什么可以拿来做什么，它只认真的做了一件事授权（Authorization）。OAuth2.0是 Open Authorization 2.0的简称，既然是2.0那前面肯定有个1.0。 Oauth1.0想要使用一套授权机制解决所有的授权应用场景，很显然废弃了，所以OAuth2.0协议针对不同的应用场景规定了四种获取令牌的授权认证流程。不过我还是建议先理解流程最完善的授权码许可流程，在此基础上再理解其他三种授权流程和其适用场景。

四个角色：

• 资源拥有者
• 客户端（或三方平台）
• 授权服务
• 受保护资源服务

举一个例子，我使用微信三方快速登录csdn平台，那么就可以省去我注册csdn和填写资料。其中资源拥有者比较好理解，一般就是指用户；客户端就是指csdn平台（当然这里包括csdn的服务端和前端）；授权服务就是微信的授权服务，一般会展示认证授权的页面并且让用户选择是否将头像等信息授权给csdn；受保护资源服务就是微信的头像等信息（对于一般的平台，授权服务和受保护资源服务可以是同一个服务）。

四种授权流程（一个补充协议）：

• 授权码许可类型（Authorization Code）【grant_type=authorization_code】
• 资源拥有者凭据许可类型（Resource Owner Password Credentials）【grant_type=password】
• 客户端许可类型（Client Credentials）【grant_type=client_credentials】
• 隐式许可类型（Implicit）
• PKCE协议（Proof Key for Code Exchange）

现在的三方系统的使用场景非常的多，比如三方登录、微信支付宝的支付、京东等的开放平台（允许有开发能力的商家直接使用开放平台对接系统，在自己的系统中操作在京东系统中生效）等。而这些应用场景底层都是使用OAuth2.0协议的授权码许可流程实现，其流程大致相同，如下：

 下图是微信等的支付流程，与上图大致相同：

 下面就拿csdn使用微信三方登录来梳理整个流程细节，在这之前csdn需要以客户（用户）的方式在微信的开放平台进行注册，此时微信就会颁发一个 app_id和app_secret给csdn，此后的所有流程都会带上这两个参数.

1、用户访问csdn前端，选择使用微信快速登录；

2、此时，就会将用户引导（这里是第一次重定向）到微信的授权服务；

3、微信授权服务就会基于用户的合法性，生成授权页面给用户；

4、此时用户就在京东授权页面上登录认证，并且授权，这里会涉及权限粒度，比如是否将微信头像、昵称、性别等信息授权给csdn服务；

5、授权服务器会生成一个临时过渡的授权码，并且重定向到三方服务（这里是第二次重定向）；

    此过程中授权服务会涉及使用用户名密码进行认证的过程，该登录认证可以委派给专门的登录服务（如果授权和认证服务分离），这个是唯一OAuth2.0作为授权协议其中穿插了认证的地方，所以也比较难理解该部分。

    并且该部分还需要1）、验证三方服务的备案资格即 app_id和app_secret；2）、验证回调地址是否正确（即第二次重定向的地址）3）、用户授权的权限范围验证生成授权码【OAuth规范建议授权码有效期为 10分钟，并且只能使用一次。一般生成环境建议是 5分钟】，生成的授权码与已经授权的权限范围 scope进行绑定存储 4）、重定向到三方软件

6、三方的客户端重定向到三方的服务端后，服务端就会根据授权码向授权服务申请获取访问令牌access_token（和刷新令牌refresh_token）；

    这里同样要验证第三方软件是否存在和合法性，并且验证授权码code值的合法性，验证后应该马上删除授权码值，防止其他恶意访问。

7、三方服务获取到访问令牌后就可以去调用受保护资源服务，比如这里就可以调用微信获取用户信息、头像的url等， 后续在访问令牌失效前就可以使用刷新令牌换取新的访问令牌了；

整个授权码许可流程梳理完了，一般会有比较多的疑问，

1、认证流程不使用授权码直接使用 access_token可以吗？

    如果值使用access_token那么只发生一次重定向（即三方平台引导用户重定向到授权服务页面），那么授权服务直接生成 access_token之后可以下发到浏览器或者三方服务器（即三方服务器的前端和后端），但是认证码是安全性要求不高的，而access_token是安全性要求比较高的，最好不要下发到前端。 那么下发到三方服务器端后，就断开了与用户的联系，用户一直停留在授权页面。 所以增加额外的授权码流程，增加一次重定向是为了增加安全性和用户体验。

2、认证流程一点要浏览器参与吗？

    浏览器只是初期所有的服务基本都是浏览器实现的，而 Oauth2.0协议只是一种思想或者协议，比如微信的授权服务，就是使用完整的 OAuth2.0 授权码许可流程实现，小程序使用微信的sdk内部发起了重定向操作。或者可以理解，浏览器只是作为三方的前端而已，前端可以使用浏览器也可以不是浏览器。

3、为什么需要刷新token？

   前提是 grant_type为 授权码许可类型 或 资源拥有者凭据许可类型。 不能token失效时间为 30分钟，那么用户使用三方软件时，每三十分钟就要去用户去登录一次并进行授权操作，而是可以进行续租，不用用户参与增加用户体验。

生成的访问令牌和刷新令牌有以下要求：

• 符合三个原则：唯一性、不连续性、不可猜性
• token要与 哪个第三方服务、哪个用户、哪个权限范围 进行绑定存储（redis或者数据库或者jwt）
• token要设置一个过期时间 expires_in，比如 30分钟

访问令牌会对应一定的操作权限，一般可以根据几个维度进行设计：

• 不同权限对应不同的操作，比如：新增权限、修改权限、删除权限、查看权限
• 不同权限对应不同的数据，一般是公有资源：比如官方的 天气信息、位置信息等
• 不同用户对应不同数据，对应用户自己的 订单数据、商品数据

OAuth2.0规范只规定了一种Bearer令牌，所以很多令牌都是以“Bearer ”中间加一个空格开始，当然也可以不用。官方规范给出了三种访问令牌请求方式，我所接触的都是使用请求头获取的方式:

Form-Encoded Body Parameter【表单参数】

POST /resource HTTP/1.1 Host: server.kevin.com Content-Type: application/x-www-form-urlencoded access_token=b1a64d5c-5e0c-4a70-9711-7af6568a61fb

URI Query Parameter【URI请求参数】

GET /order/data?access_token=b1a64d5c-5e0c-4a70-9711-7af6568a61fb HTTP/1.1 Host: server.kevin.com

Authorization Request Header Field【授权请求头部字段】
推荐使用，大多数公司也使用该方式

GET /resource HTTP/1.1 Host: server.kevin.com Authorization: Bearer b1a64d5c-5e0c-4a70-9711-7af6568a61fb