Oauth2 簡介

包括：

一. OAuth 概念

二. OAuth 運行流程

三. OAuth 授權模式

一. OAuth 概念

        OAuth 是一個開放標準，允許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密的資源（如照片，視頻，聯繫人列表），而不需要將用戶名和密碼提供給第三方應用。OAuth允許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。每一個令牌授權一個特定的網站在特定的時段內訪問特定的資源。這樣，OAuth讓用戶可以授權第三方網站訪問他們存儲在另外服務提供者的某些特定信息，而非所有內容。

二.OAuth 運行流程

首先會有幾個術語：

• Resource owner : 資源所有者，本文中稱爲 “用戶”。
• Authorization server ：認證服務器，即服務提供商專門用來處理認證的服務器。
• Resource server：資源服務器，即用戶提供商存放用戶生成的資源的服務器。它和認證服務器，可以是同一臺服務器，也可以是不同的服務器。

總的來說， 認證服務器 和 資源服務器 都由 服務提供商 提供。

流程如下圖1：

圖1

文字解釋：

1. A  用戶打開客戶端以後，客戶端要求用戶給予授權。
2. B  用戶同意給予客戶端授權。
3. C  客戶端使用上一步獲得的授權，向認證服務器申請令牌。
4. D  認證服務器對客戶端進行認證後，確認無誤後，同意發放令牌。
5. E  客戶端使用令牌，向資源服務器申請獲取資源。
6. F  資源服務器確認令牌無誤後，同意向客戶端開放資源。

上面的 6 個步驟中，重點在於 2 ，即用戶怎麼給客戶端授權，有了這個授權，客戶端就可以獲取令牌，進而憑藉令牌獲取資源。

三. OAuth 授權模式

OAuth2.0 定義了 四種授權模式。分別爲：

• 授權碼模式
• 簡化模式
• 密碼模式
• 客戶端模式

3.1 授權碼 模式

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

流程如下圖2：

圖2

解釋：

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

https://www.example.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

• www.example.com/v1/oauth/authorize ：API 授權的終端。
• client_id ：應用程序的client ID，用於 API 識別應用程序。
• redirect_uri ：獲得授權碼之後，服務提供商重定向用戶代理（比如瀏覽器）的地址。
• response_type ： 表明授權類型，默認是 code。即授權碼模式。
• scope： 應用程序可以獲得的授權級別，默認值爲 read。
• state：表示客戶端的當前狀態，可以指定任意值，認證服務器會原封不動地返回這個值，用於抵禦CSRF 攻擊。

B  用戶選擇是否給予授權。如下圖3:

圖3

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

https://www.jianshu.com/callback?code=AUTHORIZATION_CODE

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

https://www.example.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

URI 包括：

• www.example.com/v1/oauth/authorize ：API Token的終端。
• client_id ：即 app key / consumer key ，用於驗證應用程序。
• client_secret：即 app secret / consumer secret 用於驗證應用程序。
• grant_type ：剛剛獲得的授權碼
• redirect_uri ：重定向URI，和第一步一致。

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

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read"}

包括了：

• access_token：訪問令牌
• token_type ：令牌類型
• expires_in ：過期時間，單位爲秒
• refresh_token： 更新令牌，用來獲取下一次的訪問令牌。
• scope：權限範圍。

Ps：

用如下淘寶的一個時序圖4表示：

圖4

3.2 簡化模式

        簡化模式不經過第三方應用程序的服務器，直接在瀏覽器中向認證服務器 申請令牌，跳過了“授權碼” 這個步驟，所以步驟都在瀏覽器中完成，令牌對訪問者是可見的，而且客戶端不需要認證。這種模式一般是用於客戶端應用程序，比如手機應用，桌面客戶端應用程序和運行於瀏覽器上的Web應用程序。授權令牌會交給用戶代理，再由用戶代理交給應用程序。如下圖5:

圖5

A 用戶訪問客戶端，客戶端將用戶導向認證服務器。

https://www.example.com/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

B 用戶選擇是否給予客戶端授權。如下圖6:

圖6

C 假如用戶給予授權，認證服務器將用戶導向客戶端事先指定的 “重定向URI” ，並且在 URI 的 hash 部分包含了訪問令牌。

https://www.example.com/callback#token=ACCESS_TOKEN

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

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

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

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

3.3 密碼模式

        即用戶向客戶端提供用戶名密碼。客戶端使用這些信息，向 “服務商提供商” 索要授權。在這種模式下，客戶端不得存儲密碼。這通常用在用戶對客戶端高度可信的情況下。一般，認證服務器只有在其他授權模式無法執行的情況下，才能考慮使用這種模式。如下圖7:

圖7

1. A 用戶向客戶端提供用戶名，密碼。

2. B 客戶端用用戶名，密碼發送給認證服務器，向後者申請令牌。

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

3.4 客戶端模式

        客戶端使用自己的名義，而不是用戶的名義，向“服務提供商” 進行認證。嚴格來說，客戶端模式並不屬於OAuth 框架所需要解決的問題。在這種模式下，用戶直接向客戶端註冊，客戶端以自己的名義要求“服務提供商”提供服務，其實並不存在授權。圖下圖5:

圖5

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

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

        對於這種方式，試用在 訪問一些和用戶無關的Open Api，比如一些首頁數據，這些數據和用戶無關，但是又不想任何人都可以調用這個WebApi，那麼就可以採用這種模式。

參考：

1. 理解OAuth 2.0

2. 基於OWIN WebAPI 使用OAuth授權服務【客戶端模式(Client Credentials Grant)】

3. 說說OAuth那點事