认证授权：学习OAuth协议

1、什么是OAuth协议？

　　OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。同时，任何第三方都可以使用OAuth认证服务，任何服务提供商都可以实现自身的OAuth认证服务，因而OAuth是开放的。业界提供了OAuth的多种实现如PHP、JavaScript，Java，Ruby等各种语言开发包，大大节约了程序员的时间，因而OAuth是简易的。互联网很多服务如Open API，很多大公司如Google，Yahoo，Microsoft等都提供了OAuth认证服务，这些都足以说明OAuth标准逐渐成为开放资源授权的标准。

　　目前最新版本为OAuth2.0，主要参考材料为RFC 6749。

　　本文主要介绍OAuth2.0

2、思路和特点

　　思路：

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

　　特点：　　

　　(1). 简单：不管是OAuth服务提供者还是应用开发者，都很易于理解与使用；

(2). 安全：没有涉及到用户密钥等信息，更安全更灵活；

(3). 开放：任何服务提供商都可以实现OAuth，任何软件开发商都可以使用OAuth；

3、名词定义

（1）Third-party application：第三方应用程序，下图中又称"客户端"（Client：上一篇文中简书）

（2）Resource Owner：资源所有者，通常为"用户"（User：上一篇中的QQ用户）。

（3）Authorization Server：认证服务器，即服务提供商专门用来处理认证的服务器。(上一篇文中的QQ互联服务)

（4）Resource Server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。(上一篇文中的QQ信息服务)

（5）User Agent：用户代理，通常指浏览器。

（6）HTTP service：HTTP服务提供商

（7）Access Token：访问令牌，授权后得到的凭证

（8）Refresh Token：刷新令牌是用于获取访问令牌的凭据。

4、运行流程

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

步骤详解：（对应上图步骤）

（A）用户打开客户端以后，客户端要求用户给予授权。

（B）用户同意给予客户端授权。

（C）客户端使用上一步获得的授权，向认证服务器申请令牌。

（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，同意向客户端开放受保护的资源。

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

　　下面我们来讲解OAuth提供的4种授权方式。

5、客户端授权模式：

　　　客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）最后才能凭令牌获取受保护的资源

　　　OAuth 2.0定义了四种授权方式和刷新Token

授权码模式（Authorization Code）
隐式模式（Implicit Grant ）
密码模式（Resource Owner Password Credentials）
客户端模式（Client Credentials）
刷新令牌（Refresh Token）

　　5.1　授权码模式（Authorization Code）：

　　　　授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。

步骤如下：

（A）用户访问客户端，后者将前者导向认证服务器。

　　例子：https://graph.qq.com/oauth2.0/show?which=Login&display=pc&client_id=100410602&redirect_uri=http%3A%2F%2Fwww.jianshu.com%2Fusers%2Fauth%2Fqq_connect%2Fcallback&response_type=code&state=%257B%257D

　　参数：

- response_type：表示授权类型，必选项，此处的值固定为"code"
- client_id：表示客户端的ID，必选项
- redirect_uri：表示重定向URI，可选项
- scope：表示申请的权限范围，可选项
- state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。这用于防止CSRF攻击。

（B）用户选择是否给予客户端授权。　　

（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

　　例子：http://www.jianshu.com/users/auth/qq_connect/callback?code=B36BD11F2DF8ED948F8CDE81CDDD0EEB&state=%257B%257D

　　参数：　　　　

- code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
- state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。这用于防止CSRF攻击。

（D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

　　例子：https://graph.qq.com/oauth2.0/token?grant_type=authorization_code&client_id=[YOUR_APP_ID]&client_secret=[YOUR_APP_Key]&code=[The_AUTHORIZATION_CODE]&redirect_uri=[YOUR_REDIRECT_URI]

　　参数：　　

- grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。
- code：表示上一步获得的授权码，必选项。
- redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。
- client_id：表示客户端ID，必选项。

（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

　　例子：　　　　

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache　　　　

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

参数使用JSON格式发送（Content-Type: application/json）。此外，HTTP头信息中明确指定不得缓存

　　说明：

- access_token：表示访问令牌，必选项。
- token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。
- expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
- refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
- scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

　　5.2　简化模式（Implicit Grant ）：

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

步骤如下：

（A）客户端将用户导向认证服务器。

　　例子:

　　　　https://graph.qq.com/oauth2.0/authorize?response_type=token&client_id=[YOUR_APPID]&redirect_uri=[YOUR_REDIRECT_URI]&scope=[THE_SCOPE]

　参数：

- response_type：表示授权类型，此处的值固定为"token"，必选项。
- client_id：表示客户端的ID，必选项。
- redirect_uri：表示重定向的URI，可选项。
- scope：表示权限范围，可选项。
- state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

（B）用户决定是否给于客户端授权。

（C）假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。

　　参数：

- access_token：表示访问令牌，必选项。
- token_type：表示令牌类型，该值大小写不敏感，必选项。
- expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
- scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。
- state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

（D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。

（E）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。

（F）浏览器执行上一步获得的脚本，提取出令牌。

（G）浏览器将令牌发给客户端。

　　5.3　密码模式（Resource Owner Password Credentials）

　　　　密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。

　　　　在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下

步骤如下：

（A）用户向客户端提供用户名和密码。 （B）客户端将用户名和密码发给认证服务器，向后者请求令牌。
　　例子：

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=A3ddj3w

　　参数：

- grant_type：表示授权类型，此处的值固定为"password"，必选项。
- username：表示用户名，必选项。
- password：表示用户的密码，必选项。
- scope：表示权限范围，可选项。

（C）认证服务器确认无误后，向客户端提供访问令牌。
　　结果：

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
"access_token":"XXX",
"token_type":"example",
"expires_in":3600,
"refresh_token":"XXX",
"example_parameter":"XXX"
}

　　5.4　客户端模式（Client Credentials）

　　　　客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。

步骤如下：

（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。
　　　参数：

- granttype：表示授权类型，此处的值固定为"clientcredentials"，必选项。
- scope：表示权限范围，可选项。

（B）认证服务器确认无误后，向客户端提供访问令牌。
　　　结果：

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"example_parameter":"example_value"
}

　　5.5　刷新令牌（Refresh Token）

步骤：

（A）客户端通过与授权服务器进行身份验证并提供授权授权来请求访问令牌。

（B）授权服务器对客户端进行身份验证并验证授权，如果有效，则发出访问令牌和刷新令牌。
（C）客户端通过提供访问令牌向资源服务器发出受保护的资源请求
（D）资源服务器验证访问令牌，如果有效，则为请求提供服务结果
（E）重复步骤（C）和（D），直到访问令牌过期。如果客户机知道访问令牌已过期，它将跳到步骤（G）；否则，它将发出另一个受保护资源请求。
（F）由于访问令牌无效，资源服务器返回无效令牌错误。
（G）客户端通过向授权服务器进行身份验证并显示刷新令牌来请求新的访问令牌。客户端身份验证要求基于客户端类型和授权服务器策略。
　　例子:
　　　　POST /token HTTP/1.1
　　　　Host: server.example.com
　　　　Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
　　　　Content-Type: application/x-www-form-urlencoded
　　　　
　　　　grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
　　参数：

- granttype：表示使用的授权模式，此处的值固定为"refreshtoken"，必选项。
- refresh_token：表示早前收到的更新令牌，必选项。
- scope：表示申请的授权范围，不可以超出上一次申请的范围，如果省略该参数，则表示与上一次一致。

（H）授权服务器对客户端进行身份验证并验证刷新令牌，如果有效，则发出新的访问令牌（以及新刷新令牌）。

6、JSON Web Token (JWT)

　　JWT是一个定义一种紧凑的，自包含的并且提供防篡改机制的传递数据的方式的标准协议。

　　如下示例：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Imxpbmlhbmh1aSJ9.hnOfZb95jFwQsYj3qlgFbUu1rKpfTE6AzgXZidEGGTk

　　上面示例看着复杂，其实 JWT由3部分构成：header.payload.signature，每个部分由“.”来分割开来。

　6.1 Header

　　header是一个有效的JSON，其中通常包含了两部分：token类型和签名算法。

{

  "alg": "HS256",

  "typ": "JWT"

}

　　对这个JSON采用base64编码后就是第1部分eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。

　6.2 Payload

　　这一部分代表真正想要传递的数据，包含一组Claims，其中JWT预定义了一些Claim后面会介绍。

{

  "sub": "1234567890",

  "name": "cba"

}

　　对JSON采用base64编码后就是第2部分eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Imxpbmlhbmh1aSJ9

　6.3 Signature

　　这一部分是可选的，由于前面Header和Payload部分是明文的信息，所以这一部分的意义在于保障信息不被篡改用的，生成这部分的方式如下：

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

　　token生成方使用header中指定的签名算法对“header.payload”部分进行签名，得到的第3部分hnOfZb95jFwQsYj3qlgFbUu1rKpfTE6AzgXZidEGGTk,然后组合成一个完整的JWT字符串 . 而token消费方在拿到token后, 使用同样的签名算法来生成签名，用来判断header和payload部分有没有被篡改过，因为签名的密钥是只有通信双方知道的，所以可以保证这部分信息不被第三方所篡改。

　6.4 JWT的一些Claims

JWT规范中预先定义了一些Cliam，但并不是必选的，常用的有：

iss（Issuer签发者）。
sub（subject签发给的受众，在Issuer范围内是唯一的）。
aud（Audience接收方）。
exp（Expiration Time过期时间）。
iat（Issued At签发时间）等等。

后续：

　　后续将继续介绍认证授权-中ODIC的内容

引用：

OAuth：https://oauth.net/2/
RFC6749：http://www.rfcreader.com/#rfc6749
Token Introspection：http://www.rfcreader.com/#rfc7662
Token Revocation ：http://www.rfcreader.com/#rfc7009
JWT：http://www.rfcreader.com/#rfc7519