OAUTH 2.0在客戶端的應用（一）

時間 2019-11-16

原文原文鏈接

最近項目中的一個移動APP使用到了OAUTH來進行認證，期間涉及到了OAUTH插件升級問題，藉此機會從新回顧一下OAUTH的一些概念，本篇首先介紹OAUTH基礎及應用最爲普遍的受權碼模式。html

1.首先看看OAuth是什麼

OAuth(開放受權)是一個開放標準，其容許第三方應用在用戶受權的前提下訪問在用戶在服務商那裏存儲的資源。而且這種受權無需將用戶提供用戶名和密碼提供給該第三方應用。瀏覽器

2.Auth應用場景舉例

OAUTH的主要應用場景是第三方應用訪問某項服務的資源；而其一個主要優勢則是無需用戶暴露用戶名密碼給第三方應用。前幾年我利用業餘時間在WP平臺開發了一個App 「駝駝微博」，
駝駝是一個WP平臺下新浪微博的第三方客戶端(兩年未更新已下架)，然而駝駝做爲我的出品的第三方微博外殼，自己並不提供任何數據及服務，須要訪問「用戶」在「服務商」（即新浪微博）存儲的數據，那麼駝駝如何取得微博的信任和受權呢？最簡單的辦法莫過於在駝駝裏面直接輸入微博的用戶名密碼來經過微博的認證，從而訪問微博的數據和服務。這種作法簡單粗暴，但存在如下明顯缺陷：安全

用戶在駝駝中輸入微博的用戶名和密碼，直接將密碼暴露給了駝駝。服務器
駝駝並沒有利用密碼的非法之心，但爲了方便也會存儲用戶的密碼，會帶來潛在的泄露隱患。cookie
微博也不得不暴露密碼登錄，然而這並不安全。app
用戶爲了收回駝駝的權限，只能更改密碼。但會影響全部基於微博的第三方應用。
OAUTH的出現，解決了以上場景的全部問題。url

3.AUTH的流程

OAUTH在「客戶端」和「服務端」之間設置了一箇中間層專門用來受權；用戶在「客戶端」中經過「受權層」進行用戶密碼的輸入取得「服務端」受權，另外一方面「服務端」返回給「客戶端」的是一個token，以後客戶端對服務端全部資源的訪問都須要經過此token才能經過驗證；沒圖我還說個什麼呢，看看官方圖，簡單直觀：
spa

3.1術語約定

上圖中有一些術語，在此先統一術語以幫助咱們更好的理解：插件

Third-party application：第三方應用，亦即客戶端（client），即上一節例子中的"駝駝"。3d
HTTP service：服務提供商，即上一節例子中的新浪微博。
Resource Owner：資源的擁有者，能夠理解爲用戶，即上一節例子中的微博用戶/駝駝用戶
User Agent：用戶代理，多爲瀏覽器。
Authorization server：認證服務器，服務提供商專門用來處理OAUTH認證的服務器。
Resource server：資源服務器，即服務提供商存放用戶資源的服務器。上一節例子中的話就是新浪微博的服務器。

3.1流程解釋

接下來咱們對官方流程圖中各步驟簡述以下：
（A）用戶打開客戶端之後，客戶端顯示要求用戶給予受權的頁面。
（B）用戶贊成給予客戶端受權。
（C）客戶端使用上一步得到的受權，向認證服務器申請令牌。
（D）認證服務器對客戶端進行認證之後，確認無誤，贊成發放令牌。
（E）客戶端使用令牌，向資源服務器申請獲取資源。
（F）資源服務器校驗令牌，無誤則向客戶端返回所請求的資源。

以上只是一個總體流程概述，實際上客戶端具體實現有時並不須要徹底遵循這個套路，那麼客戶端具體如何實現呢？ OAUTH 提供了四種方式知足不一樣客戶端得不一樣須要：

受權碼模式（authorization code）
簡化模式（implicit）
密碼模式（resource owner password credentials）
客戶端模式（client credentials）

咱們逐一來看：

4.1受權碼：

（請注意圖中A B C分別被拆分爲兩部分，兩部分中間經過User-Agent發生交互）

4.1.1圖中出現的幾個新術語， 在此先行說明一下：

Client Identifier：認證服務器用以標識客戶端（Client）的惟一標識字符串。客戶端會提早申請該ID。
Redirection URL：用戶（Resource Owner）與認證服務器完成交互後，認證服務器會將用戶的瀏覽器（User-Agent）重定向到這個URL並附帶上受權碼。

4.1.2具體解釋受權碼模式下的流程

（A）用戶打開客戶端，客戶端經過瀏覽器（即圖中的 User Agent）將用戶導向請求認證頁面。此步驟中用戶客戶端會同時附帶一系列參數包括：Client Identifier ， request scope，redirection URL，State等。
（B）用戶（resource owner）選擇是否給予客戶端(Client & User-Agent)受權。
（C）假定用戶贊成受權，認證服務器將用戶導向客戶端事先指定的"重定向URI"（redirection URI，實際上重定向的實際動做由User-Agent完成），並在後面附上受權碼 （同時也會附上Redirection URL和State的值，若是步驟A中再請求中包括這這些參數值的話）。
（D）客戶端收到受權碼，向認證服務器令牌頒發Endpoint申請令牌(Access Token)。這一步會利用上一步獲取的受權碼和Redirection URL做爲憑證之一。
（E）認證服務器覈對受權碼和Redirection URI，確認無誤後，向客戶端發送訪問令牌（access token）和更新令牌（refresh token，可選）。

4.1.3 受權碼模式下的Authorization Request (圖4.1 中的步驟A)
由認證服務器提供服務，圖4.1的步驟A中，申請認證的客戶端須要調用該服務，並附帶如下參數：

-response_type：REQUIRED. 且值必須爲 "code".
-client_id：REQUIRED. 客戶端再認證服務器登記的惟一標識.
-redirect_uri：OPTIONAL. 重定向URL，用以校驗並接受受權碼.
-scope：OPTIONAL.
-state：RECOMMENDED. 推薦參數，客戶端應該使用此參數來避免跨站點的僞造請求攻擊.（好比在步驟A中經過將值設置爲本地某項cookie的hashcode而使該值惟一，在步驟C中認證服務器將一樣的值返回給客戶端，客戶端能夠對值進行驗證。）
-請求示例：

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

4.1.3.1 Authorization Request 的response

-code：REQUIRED. 認證服務器返回給客戶端的受權碼.OAUTH協議推薦驗證碼有效期不要超過10分鐘，而且一個受權碼只能被客戶端使用一次。
-state：REQUIRED. 詳見4.1.3中State請求參數的解釋.

4.1.4 受權碼模式下的AccessToken Request（圖4.1中的步驟D） 
由認證服務器提供，　圖４.１的步驟Ｄ中，　客戶端向認證服務器申請訪問令牌時所調用的服務。參數包括：

-response_type：REQUIRED. 且值必須爲 "authorization_code".
-code：REQUIRED.圖4.1中的步驟C中從認證服務器獲取的受權碼.
-redirect_uri：REQUIRED. 若是在4.1.3的請求中有這個參數的值，則同4.1.3中的值一致。若是4.1.3請求中該參數值爲空，則本次請求必須填入認證服務器提供的默認redirect_uri值。
-scope：OPTIONAL.
-state：RECOMMENDED. 推薦參數，客戶端應該使用此參數來避免跨站點的僞造請求攻擊.（好比在步驟A中經過將值設置爲本地某項cookie的hashcode而使該值惟一，在步驟C中認證服務器將一樣的值返回給客戶端，客戶端能夠對值進行驗證。）
請求示例：

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
 
4.1.4.1 受權碼模式下的AccessToken Request的response
-access_token: 申請到的訪問令牌， 到此爲止， 申請認證的過程即告一段落， 後續客戶端對服務提供商每一個資源的訪問都須要提供該令牌
-expires_in:令牌失效時間，單位爲秒。
-refresh_token: 當access token已經失效的狀況下， 可用來申請新的access token。 後續會詳細說明。

受權碼模式是OAUTH協議中最爲完善的受權模式，也是OAUTH推薦使用的。
本篇內容詳細介紹了OAUTH的概念以及受權碼模式，後續篇章會繼續介紹剩下的幾種受權模式，以及OAUTH協議在咱們項目中的實際使用。

參考資料：
https://tools.ietf.org/html/r...

（待續）