探索OAuth2.0授权过程

简介

OAuth 2.0 一词中的 “Auth” 表示 “授权”，字母 “O” 是 Open 的简称，表示 “开放” ，连在一起就表示 “开放授权”。看到这里，肯定能想到还有OAuth1.0，且看1.0有什么不足之处：

在 OAuth 1.0 的时候，它有个 “很大的愿望” 就是想用一套授权机制来应对现实中的所有场景，比如 Web 应用场景、移动 App 应用场景、官方应用场景等等，但是这些场景并不是完全相同的。

到了OAuth2.0，就解决了1.0面临的这种尴尬。

OAuth 2.0 不再局限于一种授权机制，它扩充了授权许可机制类型，有了授权码许可机制、客户端凭据机制、资源拥有者凭据机制和隐式许可机制。这样的 OAuth 机制就能够很灵活地适应现实中的各种场景，比如移动应用的场景、官方应用的场景，等等。

现在我们只需要学习OAuth2.0即可。

那OAuth2.0到底是什么？总结的来说，OAuth 2.0 就是一种授权协议。 这种授权协议，就是保证第三方（软件）只有在获得授权之后，才可以进一步访问授权者的数据。

现在访问授权者的数据主要是通过 Web API，所以凡是要保护这种对外的 API 时，都需要这样授权的方式。而 OAuth 2.0 的这种颁发访问令牌的机制，是再合适不过的方法了。同时，这样的 Web API 还在持续增加，所以 OAuth 2.0 是目前 Web 上重要的安全手段之一了。

OAuth 2.0 授权过程

授权过程及为什么需要授权码

关于授权流程和相关一些疑问，有大佬已经总结的很好了，就不再赘述。

OAuth 2.0实战(二)-为什么要先获取授权码code?

授权码和访问令牌的颁发流程

授权服务就是负责颁发访问令牌的服务。更进一步地讲，OAuth 2.0 的核心是授权服务，而授权服务的核心就是令牌。那么，授权服务到底是怎么生成访问令牌的，这其中包含了哪些操作呢？还有一个问题是，访问令牌过期了而用户又不在场的情况下，又如何重新生成访问令牌呢？

颁发授权码code

在这个过程中，授权服务需要完成两部分工作，分别是准备工作和生成授权码 code。

1. 验证基本信息

验证基本信息，包括对第三方软件的合法性和回调地址合法性进行校验。

在 Web 浏览器环境下，颁发 code 的整个请求过程，都是浏览器通过前端通信来完成，这就意味着所有信息都有被冒充的风险。因此，授权服务必须对第三方软件的存在性做判断。

同样，回调地址也是可以被伪造的。比如，不法分子将其伪装成钓鱼页面，或者是带有恶意攻击性的软件下载页面。因此从安全上考虑，授权服务需要对回调地址做基本的校验。

在授权服务的程序中，这两步验证通过后，就会生成或者响应一个页面（属于授权服务器上的页面），以提示用户进行授权。

2. 验证权限范围（第一次）

既然是授权，就会涉及范围。

这就意味着，我们需要对用户传过来的 scope 参数，与用户注册时申请的权限范围做比对。如果请求过来的权限范围大于注册时的范围，就需要作出越权提示。记住，此刻是第一次权限校验。

3. 生成授权请求页面

至此，颁发授权码 code 的准备工作就完成了。当用户点击授权按钮后，才会生成授权码 code 值和访问令牌 acces_token 值，“一切才真正开始”。

4.验证权限范围（第二次）

第二次验证权限范围，是用户进行授权之后的权限，再次与第三方软件注册的权限做校验。

那这里为什么又要校验一次呢？因为这相当于一次用户的输入权限。用户选择了一定的权限范围给到授权服务，对于权限的校验我们要重视对待，凡是输入性数据都会涉及到合法性检查。

另外，这也是要求我们养成一种在服务端对输入数据的请求，都尽可能做一次合法性校验的好习惯。

5.处理授权请求，生成授权码code

当用户同意授权之后，授权服务会校验响应类型 response_type 的值。response_type 有code 和 token 两种类型的值。在这里，我们是用授权码流程来举例的，因此代码要验证 response_type 的值是否为 code。

在授权服务中，需要将生成的授权码 code 值与 app_id、user 进行关系映射。也就是说，一个授权码 code，表示某一个用户给某一个第三方软件进行授权。同时，我们需要将 code 值和这种映射关系保存起来，以便在生成访问令牌 access_token 时使用。

但是授权码是临时的，一次性的凭证，因此我们还需要为code设置一个有效期。

OAuth 2.0 规范建议授权码 code 值有效期为 10 分钟，并且一个授权码 code 只能被使用一次。

同时，授权服务还需要将生成的授权码 code 跟已经授权的权限范围 rscope 进行绑定并存储，以便后续颁发访问令牌时，我们能够通过 code 值取出授权范围并与访问令牌绑定。因为第三方软件最终是通过访问令牌来请求受保护资源的。

6. 重定向至第三方软件

颁发授权码 code 是通过前端通信完成的，因此这里采用重定向的方式。这是属于第二次重定向了（在开头给出的那个链接中有详细说明）。

到此，颁发授权码 code 的流程全部完成。当小兔获取到授权码 code 值以后，就可以开始请求访问令牌 access_token 的值了。

颁发访问令牌access_token

当用户拿着授权码 code 来请求的时候，授权服务需要为之生成最终的请求访问令牌。这个过程主要包括验证第三方软件是否存在、验证 code 值是否合法和生成 access_token 值这三大步。

1. 验证第三方软件是否存在

由于颁发访问令牌是通过后端通信完成的，所以这里除了要校验 app_id 外，还要校验 app_secret。

2. 验证授权码code值是否合法

授权服务在颁发授权码 code 的阶段已经将 code 值存储了起来，此时对比从 request 中接收到的 code 值和从存储中取出来的 code 值。

这里我们一定要记住，确认过授权码 code 值有效以后，应该立刻从存储中删除当前的 code 值，以防止第三方软件恶意使用一个失窃的授权码 code 值来请求授权服务。

3. 生成访问令牌access_token值

关于按照什么规则来生成访问令牌 access_token 的值，OAuth 2.0 规范中并没有明确规定，但必须符合三个原则：唯一性、不连续性、不可猜性。

和授权码 code 值一样，我们需要将访问令牌 access_token 值存储起来，并将其与第三方软件的应用标识 app_id 和资源拥有者标识 user 进行关系映射。也就是说，一个访问令牌 access_token 表示某一个用户给某一个第三方软件进行授权。

同时，授权服务还需要将授权范围跟访问令牌 access_token 做绑定。最后，还需要为该访问令牌设置一个过期时间 expires_in。

说到过期时间先拓展一点，**设置过期时间意味着访问令牌会在一定的时间后失效。也就是资源拥有者给第三方软件的授权失效了，第三方软件无法继续访问资源拥有者的受保护资源了。**这时需要重新授权，但是用户体验糟糕。于是OAuth2.0引入了刷新令牌的概念，也就是刷新访问令牌 access_token 的值。这就意味着，有了刷新令牌，用户在一定期限内无需重新点击授权按钮，就可以继续使用第三方软件。下面让我们详细来看一看。

使用刷新令牌

在 OAuth 2.0 规范中，刷新令牌是一种特殊的授权许可类型，是嵌入在授权码许可类型下的一种特殊许可类型。在授权服务的代码里，当我们接收到这种授权许可请求的时候，会先比较 grant_type 和 refresh_token 的值，然后做下一步处理。

使用步骤

1. 接受刷新令牌请求，验证基本信息

此时请求中的 grant_type 值为 refresh_token。

和颁发访问令牌前的验证流程一样，这里我们也需要验证第三方软件是否存在。需要注意的是，这里需要同时验证刷新令牌是否存在，目的就是要保证传过来的刷新令牌的合法性。

另外，我们还需要验证刷新令牌是否属于该第三方软件。授权服务是将颁发的刷新令牌与第三方软件、当时的授权用户绑定在一起的，因此这里需要判断该刷新令牌的归属合法性。

一个刷新令牌被使用以后，授权服务需要将其废弃，并重新颁发一个刷新令牌。

2. 重新生成访问令牌

生成访问令牌的处理流程，与颁发访问令牌环节的生成流程是一致的。授权服务会将新的访问令牌和新的刷新令牌，一起返回给第三方软件。过程不再赘述。

思考

问： 用refresh刷新access时，如果access没过期，那会给这个access续期而不会重新生成？无限续期会增加access被破解的风险？

1. 若access_token未超时，那么进行refresh_token有两种方式:

   • 不会改变access_token，但超时时间会刷新，相当于续期access_token；
   • 更新access_token的值，我们建议【统一更新access_token的值】。

2. 延期access_token并不是一个最好的方式，尽管有的开放平台是这么做的。

3. 刷新令牌有过期时间。

问： 为什么要通过刷新令牌让第三方不断刷新token有效期，而不是直接给访问token一个更长的有效期？

为了安全性的考虑，是不可以让“token一个更长的有效期”存在的。