为什么需要oAuth

如果你接触网络的时间比较早，你应该能体会到网站注册登录方式的变化：

• 早期需要你输入用户名，密码，然后要输入邮箱，基于邮件来完成注册验证，然后使用用户名密码来登录。因为当时邮箱是相对比较普及的。我当时在大学里学习计算机，老师布置的第一个任务就是去注册个邮箱。
• 后来手机普及了，网站注册登录的方式是输入手机号，收到验证码来验证注册登录
• 再后来，可以直接基于微信、微博、QQ三方授权的方式来进行登录

你会发现，注册登录的方式越来越简单：

• 在早期你必须在每个你需要登陆的网站来注册账号密码，相同的账号密码吧，怕被盗了一个密码，其它全部被盗。不同的账号密码吧，记起来又费劲。后来出现了专门帮人管理密码的软件，不记得叫什么了。
• 使用手机号码的方式，你可以基于验证码来进行临时登录，不过每次输入验证码也挺麻烦的
• 三方授权的方式（也就是oAuth）只需要点击确定授权，即可以登录访问，免去了注册、验证、再登陆的麻烦

可以看出，现在微信、微博、QQ这些用户基数大的软件，替代了当初的邮箱、手机，变成了注册登录的基础设施。而且更加的安全：

• 通过邮箱注册，假设你访问了一些不正经的网站，邮箱被泄露后，会收到一堆垃圾邮件
• 通过手机号注册，手机号被泄露后，会收到一堆的骚扰电话
• 而oAuth不会存在泄露的问题，除非微信、微博、QQ泄露了你的信息！

同时你也不需要记一堆乱七八糟的密码了，只需要记着微信、微博、QQ的账号密码就可以了。

另一方面，对开发者来说，也省去了对账号体系的管理，只需要遵循oAuth规范来接入微信、微博、QQ即可，降低了开发成本。

了解了oAuth的作用，我们来看一看oAuth的实现。

oAuth的概念

前段时间阅文集团合同事件闹得沸沸扬扬，其中一个主要的问题就是资源所属问题，合同里规定作者写的作品归阅文集团所有！网友立马就炸了，那作品到底归作者所有还是阅文集团所有呢？oAuth协议里已经给出了答案。

oAuth定义了四个角色：

• 资源拥有者（resource owner）：绝大部分情况下，指的是用户。
• 资源服务器（resource server）：指的是服务提供商用来提供服务的服务器。
• 客户端（client）：即三方应用，需要用户来授权访问的应用
• 授权服务器（authorization server）：即服务提供商专门用来处理授权认证的服务器。

OAuth 2.0的运行流程如下图：

 

假设我们要通过阅文来登录一个第三方网站：

• 「资源拥有者」打开「网站」以后，该「网站」要求「资源拥有者」给予授权
• 「资源拥有者」同意「网站」授权，「网站」接收到授权凭证。这里的授权方式取决于「网站」请求方式以及「授权服务器」所支持的方式。oAuth2.0协议里定义了四种方式，包括：授权码模式、简化模式、密码模式和客户端模式，后面会具体说明。当然也可以自定义。
• 「网站」使用上一步获得的授权，向「认证服务器」申请令牌
• 「认证服务器」对「网站」进行认证以后，确认无误，同意发放令牌
• 「网站」使用令牌，向「资源服务器」申请获取资源
• 「资源服务器」确认令牌无误，同意向「网站」开放资源

流程里很明显：

• 「网站」就是Client
• 「认证服务器」就是AuthorizationServer，属于阅文
• 「资源服务器」就是ResourceServer，也属于阅文
• 而「资源拥有者」指的就是用户。你用阅文集团来替换「资源拥有者」，就会发现流程明显有问题。

从上面的流程可以看出，整个流程中「三方网站」没有获取到用户的任何敏感信息，且获取的信息需要用户主动授权后才能获取到，保证了安全性和便利性。

oAuth的分类

下面来一个个的说明具体的授权模式。在开始之前，需要多理解几个概念：

• User-Agent：用户代理，绝大部分情况下可以直接理解为浏览器
• Web Hosted Client Resource：网络托管的客户端资源，这里可以理解为托管网络脚本的服务器

授权码模式（Authorization Code Grant）

 

授权码模式是功能最完整、流程最严密的授权模式。它通过Client的后台服务器，与「服务提供商」的认证服务器进行互动置换token。具体流程如下：

• 「用户」基于浏览器访问「客户端」，「客户端」重定向到「认证服务器」对应页面，引导的参数上会附带一个「重定向URI」，指向的是「客户端」页
• 「用户」选择是否授权
• 授权后，「认证服务器」根据「重定向URI」将浏览器引导回「客户端」页，同时会附带一个授权码
• 「客户端」接收到授权码后，通过后台服务器，携带这个授权码以及「重定向URL」，向「认证服务器」申请令牌
• 「认证服务器」校验无误后，向「客户端」发送令牌（AccessToken）和更新令牌（RefreshToken）

更新令牌(RefreshToken)的作用下文说明

简化模式（Implicit Grant）

 

简化模式不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤。所有步骤在浏览器中完成，令牌对用户是可见的，且客户端不需要认证。具体流程如下：

• 「用户」基于浏览器访问「客户端」，「客户端」重定向到「认证服务器」对应页面，引导的参数上会附带一个「重定向URI」，指向的是「客户端」页
• 「用户」选择是否授权
• 授权后，「认证服务器」根据「重定向URI」将浏览器引导回「客户端」页，在URI的Fragment中会附带访问令牌
• 「客户端」浏览器根据指令向「Web Hosted Client Resource」发送请求，该请求不包括上一步收到的Fragment，浏览器本地保存Fragment
• 「Web Hosted Client Resource」返回一个网页（通常是一个包含脚本的网页，如果你理解JSONP，应该比较容易理解），这段脚本是可以从Fragment中解析出访问令牌的
• 浏览器执行脚本获取令牌
• 浏览器将令牌发放给客户端

密码模式（Resource Owner Password Credentials Grant）

 

相对于上面两种授权模式，密码模式相对的不安全，因为用户需要向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。虽然协议里规定客户端不能存储账号密码，不过除非你非常信任客户端，否则应该不会使用这种模式。

这种授权模式的具体流程如下：

• 「用户」向「客户端」提供用户名和密码
• 「客户端」将用户名和密码发送给「认证服务器」，请求令牌
• 「认证服务器」验证后，返回访问令牌

客户端模式（Client Credentials Grant）

 

客户端模式下，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务。具体流程如下：

• 「客户端」向「认证服务器」进行身份认证，并要求一个访问令牌
• 「认证服务器」验证后，返回访问令牌

更新令牌

在上面的流程中，认证服务器认证后返回的数据，除了访问令牌，还有一个更新令牌。我们知道了，通过访问令牌我们才能够访问资源，那更新令牌是做什么用的呢？

我们都知道，一般网站登录会有一个超时时间，这里也不例外。访问令牌也有一个超时时间。更新令牌就是用于在访问令牌过期后来获取新的访问令牌的。

 

• 「客户端」向「授权服务器」进行认证，获取access token。
• 「授权服务器」验证「客户端」后，发放访问令牌和刷新令牌。
• 「客户端」携带访问令牌向「资源服务器」请求资源
• 「资源服务器」验证访问令牌，如果有效，则提供服务。
• 重复步骤3和4直到访问令牌到期
• 当访问令牌无效，「资源服务器」返回无效的令牌错误
• 「客户端」向授权服务器进行身份验证，并携带刷新令牌来请求新的访问令牌
• 「授权服务器」验证「客户端」身份以及刷新令牌，如果有效，则发出新的访问令牌（以及可选的新刷新令牌）

最后补充

在上面的流程中，实际还缺少了一步，就是注册客户端。如果你接过微信、微博或QQ的授权登陆，那么应该清楚，在开始接入之前，我们需要在他们的开放平台上申请我们的应用，申请成功后会给我们一个AppId和一个appSecrect。

这个的appId就是用来唯一确定客户端的。而appSecrect就是在授权模式中，客户端的后台与授权服务器交互时需要连同code，appId一起提供的，用于置换访问令牌的。

总结

本文解释了oAuth的作用，并梳理了oAuth的具体流程。

参考文档

• 《The OAuth 2.0 Authorization Framework》https://www.ietf.org/rfc/rfc6749.txt