OAuth 2.0 ——授权码模式

OAuth 是一个关于授权（authorization）的开放网络标准，主要应用在第三方登录场景，目前的版本是2.0版。

本文主要参考材料为：

• RFC 6749
• 阮一峰的网络日志《理解OAuth 2.0》

其实，阮一峰的文章基本上就是翻译的 RFC 6749 文档，卷面很整洁，让人看起来很舒服，但是，内容却不怎么样，前后有点接不上，翻译的不全面，有些地方也没有解释清楚，本文尽量做一些补充。还有一个问题，哈，那个，就是，我觉得他翻译的挺好的地方就直接复制过来了哦。

1、应用场景

举个栗子：

当你想登陆新浪微博怼某个名人的时候，注册又嫌麻烦，然后它允许你使用 QQ 登陆。

如果你想使用 QQ 登陆，那么你就必须让新浪读取储存在QQ上的照片和昵称等信息。

问题是只有得到用户的授权，QQ 才会同意新浪读取这些信息。那么，新浪应该怎样获得用户的授权呢？
传统方法是，用户将自己的 QQ 用户名和密码，告诉新浪，然后新浪就可以读取用户的照片和昵称了。这样的做法有以下几个严重的缺点。

1. 新浪为了后续的服务，会保存用户的密码，这样很不安全。
2. QQ 不得不部署密码登录，而我们知道，单纯的密码登录并不安全。
3. 新浪拥有了获取用户储存在 QQ 所有资料的权力，用户没法限制新浪获得授权的范围和有效期。
4. 用户只有修改密码，才能收回赋予新浪的权力。但是这样做，会使得其他所有获得用户授权的第三方应用程序全部失效。
5. 只要有一个第三方应用程序被**，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。

OAuth就是为了解决上面这些问题而诞生的。

二、名词定义

在详细讲解OAuth 2.0之前，需要了解几个专用名词。它们对读懂后面的讲解，尤其是几张图，至关重要。

（1） Third-party application：第三方应用程序，本文中又称”客户端”（client），即上一节例子中的新浪。
（2）Resource Owner：资源所有者，本文中又称”用户”（user）。
（3）User Agent：用户代理，指浏览器、APP等。
（4）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
（5）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。

知道了上面这些名词，就不难理解，OAuth的作用就是让”客户端”安全可控地获取”用户”的授权，与”服务商提供商”进行互动。

三、OAuth的思路（抄阮一峰的）

OAuth在”客户端”与”服务提供商”之间，设置了一个授权层（authorization layer）。”客户端”不能直接登录”服务提供商”，只能登录授权层，以此将用户与客户端区分开来。”客户端”登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。

“客户端”登录授权层以后，”服务提供商”根据令牌的权限范围和有效期，向”客户端”开放用户储存的资料。

四、主要流程（好，下面阮一峰写的就不如我了）

OAuth 2.0 的运行流程如下图，摘自RFC 6749。

主要流程一共涉及到四个角色，客户端，用户，认证服务器和资源服务器；共六步，分别如下：

（A）授权请求。用户打开客户端终端（web or APP）以后，客户端要求用户给予授权。这个授权请求可以直接提交给资源所有者。（如图所示），或最好是间接通过授权层作为中介进行授权。

（B）用户授权。客户端收到了一个来自用户的授权凭证。这个凭证，可以通过四种方式来获取，至于哪四种，下面有介绍。

（C）请求认证服务器授权。客户端使用上面用户授权得到的凭证向认证服务器请求一个拥有特定访问权限的访问令牌（access token），注意，access token 是和权限绑定的。

（D）发放令牌。认证服务器向客户端发放客户端在上一步请求的令牌。

（E）请求资源。客户端使用访问令牌向资源服务器请求用户的受保护的资源。

（F）返回资源。资源服务器验证访问令牌是否有效，有效则返回请求的资源。如何判断是否有效呢，当然是调用认证服务器的准备好的服务了。

上面六个步骤之中，B是关键，即用户怎样才能给于客户端授权。有了这个授权以后，客户端就可以获取令牌，进而凭令牌获取资源。

下面一一讲解客户端获取授权的四种模式。

五、四种授权模式

客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0 定义了四种授权模式。

• 授权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

本文，就只对其中的授权码模式记录一下自己浅显的理解。因为，授权码模式是功能最完整、流程最严密的授权模式，也是目前使用较广泛的模式，也是我曾经接触过的模式。

六、授权码授权方式

它的特点就是通过客户端的后台服务器，与”服务提供商”的认证服务器进行互动。授权码授权方式用于同时获取 accessToken 和 refreshToken，并对信任的客户端进行了优化。由于这是一个基于重定向的流程，client 必须能与 resource owner 的 user-agent（通常是浏览器）进行交互并且能够接收到 authorization server 通过重定向传入的请求。

下面说一下上图中的流程：

（A）客户端将用户浏览器引导向认证端。客户端包含了客户端标识 client_id，请求授权范围 scope，本地状态state，回调地址 redirect_uri，一旦被授权（或被拒绝），认证服务器将会把回调地址返回给浏览器。

（B）用户操作授权，比如用户进行选择资源范围，输入密码点确定发送请求，决定是否给客户端授权。

（C）认证服务器校验用户真实性，假设用户给予授权，认证服务器将用户导向客户端事先指定的回调地址 redirect_uri，回调地址后面同时附上一个授权码 code 和之前设置的 state （这里的state，其实就是客户端预留的，用以当授权成功后，执行某些事件等，比如可以放一个js的方法名）。

（D）客户端使用上一步返回的授权码 code 附上之前用来获取授权码的回调地址 redirect_uri 向认证服务器请求一个访问令牌 （access token）。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）认证服务器核对了授权码和重定向URI，和在（C）步骤中的两个参数比对确认无误后，向客户端发送访问令牌（access token）和可选的刷新令牌（refresh token）。

我看到阮一峰博客里面还有主要流程请求以及返回的参数，我觉得没必要，说清楚原理就行了，这种细节，想怎么设定都行。

再来个时序图看看整个流程：

呃，画的有点粗糙。

在这个流程里面，有几个关键的参数，client_id，redirect_uri，code，access token，refresh token，下面简单解释一下。

client_id：客户端id。这个是认证端预先分配给客户端的。比如说，你要使用QQ登录新浪，那么新浪肯定是需要在QQ的认证中心备案的，然后 QQ 给新浪一个client_id，可能还有个secret，然后在约定一个回调地址 redirect_uri。然后新浪才能调用 QQ 的授权页面展示给用户看，让用户授权。

redirect_uri：回调地址。当你在QQ页面上授权完了，就会跳转到这个URI，就是授权成功后执行一些什么操作。如果没有这玩意的话，当你授权完了，然后呢，新浪也不知道接下来应该干嘛。

code：为什么要使用code呢？因为安全，这样，user agent 端只会出现code，正常情况下不会存在access token 和 refresh token，access token 和 refresh token只会在客户端即第三方的服务端和资源所在的服务器端流通。往往，客户端（user agent）被认为是不安全的，所以要尽量把重要的信息存在服务器端，以防止被篡改使用。

access token：即访问令牌。访问令牌用来访问资源信息，它本身就是权限，用户不可见。访问令牌的出现，可以让用户自主设定一个权限范围，也有了随时取消第三方权限的方式。它还有时效性，通常在返回该令牌的时候，也会随之返回一个有效时间，几十分钟到几十天不等，看认证服务器端的设置。OAuth 1.0 的时候，accessToken 是没有时间限制的，就是永久有效，这样的话，那第三方就能一直使用该令牌获取用户的资源，那如果用户好几个月都没有登录认证服务器设置，或者是忘记了，那么第三方就能永远可以访问，不太好，所以，在OAuth 2.0 的时候，增加了 refresh token。

refresh token：用途，看字面意思就知道，刷新令牌，当 access token 过期之后刷新出新的 access token。那就与上面的说法又矛盾了，这样一来的话，那不就是说可以一直使用 refresh token 来刷新出有效的 access token，这不就是变相的可以永久访问吗？确实，这是一个问题，所以，一般， refresh token 也是有时效性的，有过期时间，甚至，好多公司直接去掉了 refresh token ，仅仅返回有一定时间限制的 access token。那 refresh token 的存在意义又在哪里呢，应该是：有了它，可以改变 access token 的属性而不用再次经历授权。比如更改 accessToken 的权限的时候，只要使用 refresh token来刷新一个新的就好了，而不用再输入密码什么的。

应该差不多了吧，总的来说，这只是个标准，到底是否要使用，如何使用，还是要看具体业务场景。

哦对了，其他几种授权模式就不说了，看 RFC 6749 吧。