學(xué)習(xí)一下OAuth2.0協(xié)議-魔扣目錄

一、什么是OAuth協(xié)議

OAuth 協(xié)議為用戶資源的授權(quán)提供了一個(gè)安全的、開放而又簡易的標(biāo)準(zhǔn)。與以往的授權(quán)方式不同之處是 OAuth的授權(quán)不會(huì)使第三方觸及到用戶的帳號(hào)信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請(qǐng)獲得該用戶資源的授權(quán)，因此 OAuth是安全的。OAuth 是 Open Authorization 的簡寫。

OAuth 本身不存在一個(gè)標(biāo)準(zhǔn)的實(shí)現(xiàn)，后端開發(fā)者自己根據(jù)實(shí)際的需求和標(biāo)準(zhǔn)的規(guī)定實(shí)現(xiàn)。其步驟一般如下：

客戶端要求用戶給予授權(quán)
用戶同意給予授權(quán)
根據(jù)上一步獲得的授權(quán)，向認(rèn)證服務(wù)器請(qǐng)求令牌（token）
認(rèn)證服務(wù)器對(duì)授權(quán)進(jìn)行認(rèn)證，確認(rèn)無誤后發(fā)放令牌
客戶端使用令牌向資源服務(wù)器請(qǐng)求資源
資源服務(wù)器使用令牌向認(rèn)證服務(wù)器確認(rèn)令牌的正確性，確認(rèn)無誤后提供資源

二、OAuth2.0是為了解決什么問題？

任何身份認(rèn)證，本質(zhì)上都是基于對(duì)請(qǐng)求方的不信任所產(chǎn)生的。同時(shí)，請(qǐng)求方是信任被請(qǐng)求方的，例如用戶請(qǐng)求服務(wù)時(shí)，會(huì)信任服務(wù)方。

所以，身份認(rèn)證就是為了解決身份的可信任問題。

在OAuth中，簡單來說有三方：用戶（這里是指屬于服務(wù)方的用戶）、服務(wù)方、第三方應(yīng)用。

服務(wù)方不信任用戶，所以需要用戶提供密碼或其他可信憑據(jù)；

服務(wù)方不信任第三方，所以需要第三方提供自已交給它的憑據(jù)（通常的一些安全簽名之類的就是）；

用戶部分信任第三方，所以用戶愿意把自已在服務(wù)方里的某些服務(wù)交給第三方使用，但不愿意把自已在服務(wù)方的密碼交給第三方；

在oauth2.0的流程中，用戶登錄了第三方的系統(tǒng)后，會(huì)先跳去服務(wù)方獲取一次性用戶授權(quán)憑據(jù)，再跳回來把它交給第三方，第三方的服務(wù)器會(huì)把授權(quán)憑據(jù)以及服務(wù)方給它的的身份憑據(jù)一起交給服務(wù)方，這樣，服務(wù)方一可以確定第三方得到了用戶對(duì)此次服務(wù)的授權(quán)（根據(jù)用戶授權(quán)憑據(jù)），二可以確定第三方的身份是可以信任的（根據(jù)身份憑據(jù)），所以，最終的結(jié)果就是，第三方順利地從服務(wù)方獲取到了此次所請(qǐng)求的服務(wù)。

從上面的流程中可以看出，oauth2.0完整地解決掉了用戶、服務(wù)方、第三方在某次服務(wù)時(shí)這三者之間的信任問題。

三、OAuth2.0成員

Resource Owner（資源擁有者：用戶）
Client （第三方接入平臺(tái)：請(qǐng)求者）
Resource Server （服務(wù)器資源：數(shù)據(jù)中心）
Authorization Server （認(rèn)證服務(wù)器）

Oauth2.0基本流程：

原理很簡單，用戶訪問App，App訪問Authorization Server請(qǐng)求權(quán)限，

Authorization Server得到用戶同意后，返回token，

App通過這個(gè)token向Authorization Server索要數(shù)據(jù)，

App只能從Authorization Server這個(gè)中介獲取服務(wù)器數(shù)據(jù)，而無法直接訪問Resource Server。

四、第三方客戶端的授權(quán)模式

客戶端必須得到用戶的授權(quán)（authorization grant），才能獲得令牌（access token）。OAuth 2.0定義了四種授權(quán)方式。

授權(quán)碼模式（authorization code）
簡化模式（implicit）
密碼模式（resource owner password credentials）
客戶端模式（client credentials）

授權(quán)碼模式（authorization code）是功能最完整、流程最嚴(yán)密的授權(quán)模式。它的特點(diǎn)就是通過客戶端的后臺(tái)服務(wù)器，與"服務(wù)提供商"的認(rèn)證服務(wù)器進(jìn)行互動(dòng)。

它的步驟如下：

用戶訪問客戶端，后者將前者導(dǎo)向認(rèn)證服務(wù)器。
用戶選擇是否給予客戶端授權(quán)。
假設(shè)用戶給予授權(quán)，認(rèn)證服務(wù)器將用戶導(dǎo)向客戶端事先指定的"重定向URI"（redirection URI），同時(shí)附上一個(gè)授權(quán)碼。
客戶端收到授權(quán)碼，附上早先的"重定向URI"，向認(rèn)證服務(wù)器申請(qǐng)令牌。這一步是在客戶端的后臺(tái)的服務(wù)器上完成的，對(duì)用戶不可見。
認(rèn)證服務(wù)器核對(duì)了授權(quán)碼和重定向URI，確認(rèn)無誤后，向客戶端發(fā)送訪問令牌（access token）和更新令牌（refresh token）。

下面是上面這些步驟所需要的參數(shù)。

步驟1: 客戶端申請(qǐng)認(rèn)證的URI，包含以下參數(shù)：

response_type：表示授權(quán)類型，必選項(xiàng)，此處的值固定為"code"
client_id：表示客戶端的ID，必選項(xiàng)。（如微信授權(quán)登錄，此ID是APPID）
redirect_uri：表示重定向URI，可選項(xiàng)
scope：表示申請(qǐng)的權(quán)限范圍，可選項(xiàng) state：表示客戶端的當(dāng)前狀態(tài)，可以指定任意值，認(rèn)證服務(wù)器會(huì)原封不動(dòng)地返回這個(gè)值。

例子:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
HTTP/1.1 Host: server.example.com

對(duì)比微信網(wǎng)頁掃描授權(quán)請(qǐng)求CODE

 https://open.weixin.qq.com/connect/qrconnect?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=SCOPE&state=STATE#wechat_redirect

步驟3：服務(wù)器回應(yīng)客戶端的URI，包含以下參數(shù)：

code：表示授權(quán)碼，必選項(xiàng)。該碼的有效期應(yīng)該很短，通常設(shè)為10分鐘，客戶端只能使用該碼一次，否則會(huì)被授權(quán)服務(wù)器拒絕。該碼與客戶端ID和重定向URI，是一一對(duì)應(yīng)關(guān)系。
state：如果客戶端的請(qǐng)求中包含這個(gè)參數(shù)，認(rèn)證服務(wù)器的回應(yīng)也必須一模一樣包含這個(gè)參數(shù)。

例子：

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
 &state=xyz

步驟4：客戶端向認(rèn)證服務(wù)器申請(qǐng)令牌的HTTP請(qǐng)求，包含以下參數(shù)：

grant_type：表示使用的授權(quán)模式，必選項(xiàng)，此處的值固定為"authorization_code"。
code：表示上一步獲得的授權(quán)碼，必選項(xiàng)。
redirect_uri：表示重定向URI，必選項(xiàng)，且必須與A步驟中的該參數(shù)值保持一致。
client_id：表示客戶端ID，必選項(xiàng)。

例子：

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

步驟5：認(rèn)證服務(wù)器發(fā)送的HTTP回復(fù)，包含以下參數(shù)：

access_token：表示訪問令牌，必選項(xiàng)。
token_type：表示令牌類型，該值大小寫不敏感，必選項(xiàng)，可以是bearer類型或mac類型。
expires_in：表示過期時(shí)間，單位為秒。如果省略該參數(shù)，必須其他方式設(shè)置過期時(shí)間。
refresh_token：表示更新令牌，用來獲取下一次的訪問令牌，可選項(xiàng)。
scope：表示權(quán)限范圍，如果與客戶端申請(qǐng)的范圍一致，此項(xiàng)可省略。

例子：

 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,
 "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
 "example_parameter":"example_value"
 }

從上面代碼可以看到，相關(guān)參數(shù)使用JSON格式發(fā)送（Content-Type: application/json）。此外，HTTP頭信息中明確指定不得緩存。

五、更新令牌

如果用戶訪問的時(shí)候，客戶端的"訪問令牌"已經(jīng)過期，則需要使用"更新令牌"申請(qǐng)一個(gè)新的訪問令牌。客戶端發(fā)出更新令牌的HTTP請(qǐng)求，包含以下參數(shù)：

granttype：表示使用的授權(quán)模式，此處的值固定為"refreshtoken"，必選項(xiàng)。
refresh_token：表示早前收到的更新令牌，必選項(xiàng)。
scope：表示申請(qǐng)的授權(quán)范圍，不可以超出上一次申請(qǐng)的范圍，如果省略該參數(shù)，則表示與上一次一致。

例子：

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