OAuth2 認證

隨着微服務的興起，OAuth2 也火了起來，由於其自身的優勢，儼然已成爲微服務 API 服務接口安全防護的首選。

例如有一個” 雲沖印” 的網站，可以將用戶儲存在 Google 的照片，沖印出來。用戶爲了使用該服務，必須讓” 雲沖印” 讀取自己儲存在 Google 上的照片。

  1. 介紹 =====

OAuth2（Open Authorization，開放授權）是 OAuth 的升級版本。OAuth 是一個開放標準，允許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密的資源（如照片，視頻，聯繫人列表），而無需將用戶名和密碼提供給第三方應用。

OAuth 允許用戶提供一個令牌給第三方網站，一個令牌對應一個特定的第三方網站，同時該令牌只能在特定的時間內訪問特定的資源。

1.1 思路

OAuth 在” 客戶端” 與” 服務提供商” 之間，設置了一個授權層（authorization layer）。” 客戶端” 不能直接登錄” 服務提供商”，只能登錄授權層，以此將用戶與客戶端區分開來。” 客戶端” 登錄授權層所用的令牌（token），與用戶的密碼不同。用戶可以在登錄的時候，指定授權層令牌的權限範圍和有效期。

“客戶端” 登錄授權層以後，” 服務提供商” 根據令牌的權限範圍和有效期，向” 客戶端” 開放用戶儲存的資料。

1.2 角色

1.3 流程

（A）用戶打開客戶端以後，客戶端要求用戶給予授權。

（B）用戶同意給予客戶端授權。

（C）客戶端使用上一步獲得的授權，向認證服務器申請令牌。

（D）認證服務器對客戶端進行認證以後，確認無誤，同意發放令牌。

（E）客戶端使用令牌，向資源服務器申請獲取資源。

（F）資源服務器確認令牌無誤，同意向客戶端開放資源。

不難看出來，上面六個步驟之中，B 是關鍵，即用戶怎樣才能給予客戶端授權。有了這個授權以後，客戶端就可以獲取令牌，進而憑令牌獲取資源。

  1. 授權模式 =======

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

2.1 授權碼模式（authorization code）

授權碼模式（authorization code）是功能最完整、流程最嚴密的授權模式。它的特點就是通過客戶端的後臺服務器，與” 服務提供商” 的認證服務器進行互動。

（A）用戶訪問客戶端，後者將前者導向認證服務器。

（B）用戶選擇是否給予客戶端授權。

（C）假設用戶給予授權，認證服務器將用戶導向客戶端事先指定的” 重定向 URI”（redirection URI），同時附上一個授權碼。

（D）客戶端收到授權碼，附上早先的” 重定向 URI”，向認證服務器申請令牌。這一步是在客戶端的後臺的服務器上完成的，對用戶不可見。

（E）認證服務器覈對了授權碼和重定向 URI，確認無誤後，向客戶端發送訪問令牌（access token）和更新令牌（refresh token）。

下面是上面這些步驟所需要的參數。

A 步驟中，客戶端申請認證的 URI，包含以下參數：

下面是一個例子。

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https://client.example.com/cb HTTP/1.1
Host: server.example.com

C 步驟中，服務器迴應客戶端的 URI，包含以下參數：

下面是一個例子。

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

D 步驟中，客戶端向認證服務器申請令牌的 HTTP 請求，包含以下參數：

下面是一個例子。

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://client.example.com/cb

E 步驟中，認證服務器發送的 HTTP 回覆，包含以下參數：

下面是一個例子。

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"
}

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

2.2 隱藏模式（implicit）

這種方式把令牌直接傳給前端，是很不安全的。因此，只能用於一些安全要求不高的場景，並且令牌的有效期必須非常短，通常就是會話期間（session）有效，瀏覽器關掉，令牌就失效了。

簡化模式（implicit grant type）不通過第三方應用程序的服務器，直接在瀏覽器中向認證服務器申請令牌，跳過了” 授權碼” 這個步驟，因此得名。所有步驟在瀏覽器中完成，令牌對訪問者是可見的，且客戶端不需要認證。

（A）客戶端將用戶導向認證服務器。

（B）用戶決定是否給予客戶端授權。

（C）假設用戶給予授權，認證服務器將用戶導向客戶端指定的” 重定向 URI”，並在 URI 的 Hash 部分包含了訪問令牌。

（D）瀏覽器向資源服務器發出請求，其中不包括上一步收到的 Hash 值。

（E）資源服務器返回一個網頁，其中包含的代碼可以獲取 Hash 值中的令牌。

（F）瀏覽器執行上一步獲得的腳本，提取出令牌。

（G）瀏覽器將令牌發給客戶端。

下面是上面這些步驟所需要的參數。

A 步驟中，客戶端發出的 HTTP 請求，包含以下參數：

下面是一個例子。

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

C 步驟中，認證服務器迴應客戶端的 URI，包含以下參數：

下面是一個例子。

HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600

在上面的例子中，認證服務器用 HTTP 頭信息的 Location 欄，指定瀏覽器重定向的網址。注意，在這個網址的 Hash 部分包含了令牌。

根據上面的 D 步驟，下一步瀏覽器會訪問 Location 指定的網址，但是 Hash 部分不會發送。接下來的 E 步驟，服務提供商的資源服務器發送過來的代碼，會提取出 Hash 中的令牌。

2.3 密碼模式（resource owner password credentials）

密碼模式（Resource Owner Password Credentials Grant）中，用戶向客戶端提供自己的用戶名和密碼。客戶端使用這些信息，向” 服務商提供商” 索要授權。

在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲存密碼。這通常用在用戶對客戶端高度信任的情況下，比如客戶端是操作系統的一部分，或者由一個著名公司出品。而認證服務器只有在其他授權模式無法執行的情況下，才能考慮使用這種模式。

它的步驟如下：

（A）用戶向客戶端提供用戶名和密碼。

（B）客戶端將用戶名和密碼發給認證服務器，向後者請求令牌。

（C）認證服務器確認無誤後，向客戶端提供訪問令牌。

B 步驟中，客戶端發出的 HTTP 請求，包含以下參數：

下面是一個例子。

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

C 步驟中，認證服務器向客戶端發送訪問令牌，下面是一個例子。

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"
}

整個過程中，客戶端不得保存用戶的密碼。

2.4 客戶端模式（client credentials）

客戶端模式（Client Credentials Grant）指客戶端以自己的名義，而不是以用戶的名義，向” 服務提供商” 進行認證。嚴格地說，客戶端模式並不屬於 OAuth 框架所要解決的問題。在這種模式中，用戶直接向客戶端註冊，客戶端以自己的名義要求” 服務提供商” 提供服務，其實不存在授權問題。

它的步驟如下：

（A）客戶端向認證服務器進行身份認證，並要求一個訪問令牌。

（B）認證服務器確認無誤後，向客戶端提供訪問令牌。

A 步驟中，客戶端發出的 HTTP 請求，包含以下參數：

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

grant_type=client_credentials

認證服務器必須以某種方式，驗證客戶端身份。

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"
}
  1. 使用 =====

3.1 令牌的使用

A 網站拿到令牌以後，就可以向 B 網站的 API 請求數據了。
此時，每個發到 API 的請求，都必須帶有令牌。具體做法是在請求的頭信息，加上一個 Authorization 字段，令牌就放在這個字段裏面。

curl -H “Authorization: Bearer ACCESS_TOKEN” “https://api.b.com"

上面命令中，ACCESS_TOKEN 就是拿到的令牌。

3.2 更新令牌

如果用戶訪問的時候，客戶端的” 訪問令牌” 已經過期，則需要使用” 更新令牌” 申請一個新的訪問令牌。

客戶端發出更新令牌的 HTTP 請求，包含以下參數：

下面是一個例子。

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

souece： //www.liuvv.com/p/4ce15f73.html#more

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Qm7hDzqjNXZYnOMQ4vpmcg

猜你喜歡