【簡易圖解】『 OAuth2.0』 『進階』 授權模式總結

一，到底OAuth是什麼？

寫在前面的

上一次簡單傻瓜式的用圖來說明了到底什麼是OAuth，沒看過的童靴可以點選下面這條連結看一下。
看完這個在來看這篇可能理解起來效果拔群。
【簡易圖解】『 OAuth2.0』 猴子都能懂的圖解
簡而言之就是一個程式想借用下你的資料( 想借你微信朋友圈內容看一下啦，想借你微博圖片下載一下啦)所產生的一系列問題(比如安全，如何授權等等)，OAuth就是關於這些的規範。

• 接下來我想就授權模式做一下總結，還是用圖。
• 這次的圖可能沒有上次這麼傻瓜，只要仔細閱讀一下，就連我非計算機專業出身的人都能懂的話，一般的猴子們估計也沒問題。覺得太長的可以只從圖解看起，或者只看授權碼模式就好。
• 授權模式主要參考來自 RFC 6749

認證 Authentication VS 授權 Authorization

看授權模式圖之前，先區別下這兩個概念。

• 認證就是我要輸入帳號和密碼來證明我是我
• 授權就是並非通過帳號和密碼來把我的東西借給其他人
• 這其中的關鍵就是，是否需要輸入帳號密碼。記住，OAuth不需要輸入帳號和密碼，你要做的只是授權。
  下面這張圖清晰的說明了，認證和授權。
  

  二，授權模式

  如果有覺得畫質太差的，沒辦法，上傳之後就這樣了。。
  這裡是PPT連結。

• 授權碼模式
• 簡化模式
• 密碼模式
• 客戶端模式
• 重新整理令牌

1. 授權碼模式 Authorization Code

• 授權碼模式是最常見常用的模式，我們所熟悉的微博，QQ等都是這種模式。
• 另外也是最繁瑣的一種方式，如果弄懂了這個相信接下來的三種型別都會迎刃而解。
• 這種模式和其他最大的區別就在於是否有授權碼這個步驟。

  1.1 圖解

  
  
  
  
  
  
  
  
  
  
  
  

  1.2 授權請求 Authorization Request

  GET {認證終點}
  ?response_type=code           // 必選項
  &client_id={客戶端的ID}       // 必選項 
  &redirect_uri={重定向URI}    // 可選項 
  &scope={申請的許可權範圍}        // 可選項
  &state={任意值}              // 推薦
  HTTP/1.1
  HOST: {認證伺服器}

1.3 授權響應 Authorization Response

HTTP/1.1 302 Found
Location: {重定向URI}
?code={授權碼}          // 必填
&state={任意文字}       // 如果授權請求中包含 state的話那就是必填

1.4 令牌請求 Access Token Request

POST {令牌終點} HTTP/1.1
Host: {認證伺服器}
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code      // 必填
&code={授權碼}                     // 必填　必須是認證伺服器響應給的授權碼
&redirect_uri={重定向URI}          // 如果授權請求中包含 redirect_uri 那就是必填
&code_verifier={驗證碼}            // 如果授權請求中包含 code_challenge 那就是必填

根據具體情況有可能是向客戶端伺服器進行請求，這時候請加上Basic 認證（Authorization 頭部）或者是 引數 client_id & client_secret

1.5 令牌響應 Access Token Response

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

{
  "access_token":"{訪問令牌}",      // 必填
  "token_type":"{令牌型別}",      // 必填
  "expires_in":{過期時間},        // 任意
  "refresh_token":"{重新整理令牌}",   // 任意
  "scope":"{授權範圍}"            // 如果請求和響應的授權範圍不一致就必填
}

2. 簡化模式 Implicit

• 簡化模式，顧名思義，就是簡化了的模式。
• 簡化的就是授權碼這個步驟。

  2.1 圖解

  
  
  
  
  
  
  
  
  
  

2.2 授權請求 Authorization Request

GET {授權終點}
  ?response_type=token             // 必填
  &client_id={客戶端ID}      // 必填
  &redirect_uri={重定向URI}  // 可選。授權成功後的重定向地址
  &scope={授權範圍}              // 任意
  &state={任意文字}              // 推薦
  HTTP/1.1
HOST: {認證伺服器}

2.3 授權響應 Authorization Response

HTTP/1.1 302 Found
Location: {重定向URI}
  #access_token={令牌碼}       // 必填
  &token_type={令牌型別}     // 必填
  &expires_in={過期時間}       // 任意
  &state={任意文字}            // 如果授權請求中包含 state 那就是必填
  &scope={授權範圍}            // 如果請求和響應的授權範圍不一致就必填

3. 密碼模式 Resource Owner Password Credentials

• 密碼模式其實就是進一步再去簡化了簡化模式。
• 不僅僅沒有了授權碼模式下的授權碼，也沒了簡化模式下的授權請求。
• 直接就請求了令牌碼。

  3.1 圖解

  
  
  
  
  
  
  
  
  

3.2 令牌請求 Access Token Request

POST {令牌終點} HTTP/1.1
Host: {認證伺服器}
Content-Type: application/x-www-form-urlencoded

grant_type=password       // 必填
&username={使用者ID}    // 必填
&password={密碼}    // 必填
&scope={授權範圍}       // 任意

根據具體情況有可能是向客戶端伺服器進行請求，這時候請加上Basic 認證（Authorization 頭部）或者是 引數 client_id & client_secret

3.3 令牌響應 Access Token Response

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

{
  "access_token":"{訪問令牌}",   // 必填
  "token_type":"{令牌型別}",      // 必填
  "expires_in":{過期時間},        // 任意
  "refresh_token":"{重新整理令牌}", // 任意
  "scope":"{授權範圍}"              // 如果請求和響應的授權範圍不一致就必填
}

4. 客戶端模式 Client Credentials

• 客戶端模式可是最簡化的了。
• 什麼都不問，直接請求！簡單粗暴給我令牌！

  4.1 圖解

  
  
  
  
  
  

4.2 令牌請求 Access Token Request

POST {令牌終點} HTTP/1.1
Host: {認證伺服器}
Authorization: Basic {客戶端模式}
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials     // 必填
&scope={授權範圍}               // 任意

4.3 令牌響應 Access Token Response

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

{
  "access_token":"{訪問令牌}",  // 必填
  "token_type":"{令牌型別}",      // 必填
  "expires_in":{過期時間},              // 任意
  "scope":"{授權範圍}"                // 如果請求和響應的授權範圍不一致就必填
}

5. 重新整理令牌 Refresh Token

5.1 圖解

第三方已存在令牌碼為前提進行更新令牌

5.2 令牌請求 Access Token Request

POST {令牌終點} HTTP/1.1
Host: {認證伺服器}
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token           // 必填
&refresh_token={重新整理令牌}        // 必填
&scope={授權範圍}                    // 任意

根據具體情況有可能是向客戶端伺服器進行請求，這時候請加上Basic 認證（Authorization 頭）或者是 引數 client_id & client_secret

5.3 令牌響應 Access Token Response

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

{
  "access_token":"{訪問令牌}",      // 必填
  "token_type":"{令牌型別}",          // 必填
  "expires_in":{過期時間},                  // 任意
  "refresh_token":"{重新整理令牌}", // 任意
  "scope":"{授權範圍}"                    // 如果請求和響應的授權範圍不一致就必填
}

三，總結

授權模式	授權終點	令牌終點
授權碼模式	使用	使用
簡化模式	使用	不使用
密碼模式	不使用	使用
客戶端模式	不使用	使用
重新整理令牌	不使用	使用

其實授權終點就是授權請求和響應
令牌終點就是令牌的請求和響應

感謝您的閱讀！