OAuth2.0 基礎介紹
1、應用場景
2、角色說明
3、OAuth2.0 概述
4、協議流程
5、四種授權模式
6、授權碼模式
應用場景
這裏以“簡書”為例，網友希望在簡書的文章下留言，但需要先登錄。在登錄頁面，提供多種方式登錄，例如：微博、微信、QQ賬戶等。減少了網友註冊並管理多個賬戶的麻煩。但簡書如何使用微博登錄，獲取用戶信息並確保其數據不被泄露，這時 OAuth2.0 派上用場。
角色說明
1、Resource Owner
資源擁有者，能夠許可對受保護資源的訪問權限的實體。當資源所有者是個人時，它被稱為最終用戶。
2、Resource Server
資源服務器，管理受保護資源的服務器，能夠接收和響應使用訪問令牌對受保護資源的請求。例如，微博的資源服務器。
3、Client
第三方應用客戶端，資源擁有者發起對受保護資源的請求的應用程序。例如：簡書。
4、Authorization Server
授權服務器，在成功驗證資源擁有者且獲得授權後頒發訪問令牌給客戶端的服務器。例如，微博的授權服務器。
OAuth2.0 概述
OAuth2.0 授權框架允許第三方應用獲取對 HTTP 服務的有限的訪問權限，既可以以資源所有者名義在資源所有者和 HTTP 服務之間進行允許的交互，也可以允許第三方應用以自己的名義進行訪問。本規範取代並淘汰 RFC5849 中描述的 OAuth 1.0 協議。（摘自：https://github.com/jeansfish/RFC6749.zh-cn/blob/master/index.md）
協議流程
OAuth 2.0 的協議流程如下圖，摘自 RFC6749。
上圖是抽象的 OAuth 2.0 協議流程，描述了四種角色之間的交互，包括以下步驟：
- （A）客戶端從資源所有者處請求授權。授權請求可以直接向資源所有者發起，或者更可取的是通過授權服務器作為中介間接發起。
- （B）客戶端收到授權許可，這是一個代表資源所有者的授權的憑據，使用本規範中定義的四種許可類型之一或者使用擴展許可類型表示。授權許可類型取決於客戶端請求授權所使用的方法以及授權服務器支持的類型。
- （C）客戶端與授權服務器進行身份認證並出示授權許可以請求訪問令牌。
- （D）授權服務器驗證客戶端身份並驗證授權許可，若有效則頒發訪問令牌。
- （E）客戶端從資源服務器請求受保護資源並出示訪問令牌進行身份驗證。
- （F）資源服務器驗證訪問令牌，若有效則處理該請求。
客戶端從資源所有者獲得授權許可（步驟（A）和（B）所示）的更好方法是使用授權服務器作為中介，也就是授權碼模式。
四種授權模式
客戶端必須得到用戶的授權（authorization grant），才能獲得令牌（access token）。OAuth 2.0定義了四種授權方式。
- 授權碼模式（authorization code）
- 簡化模式（implicit）
- 密碼模式（resource owner password credentials）
- 客戶端模式（client credentials）
授權碼模式
授權碼許可類型用於獲得訪問令牌和刷新令牌並且為受信任的客戶端進行了優化。由於這是一個基於重定向的流程，客戶端必須能夠與資源所有者的用戶代理（通常是Web瀏覽器）進行交互並能夠接收來自授權服務器的傳入請求（通過重定向）。
註：說明步驟（A）、（B）和（C）的直線因為通過用戶代理而被分為兩部分。
上圖描述了授權碼流程，包括以下步驟：
- （A）客戶端通過向授權端點引導資源所有者的用戶代理開始流程。客戶端包括它的客戶端標識、請求範圍、本地狀態和重定向URI，一旦訪問被許可（或拒絕）授權服務器將傳送用戶代理回到該URI。
- （B）授權服務器驗證資源擁有者的身份（通過用戶代理），並確定資源所有者是否授予或拒絕客戶端的訪問請求。
- （C）假設資源所有者許可訪問，授權服務器使用之前（在請求時或客戶端註冊時）提供的重定向URI重定向用戶代理回到客戶端。重定向URI包括授權碼和之前客戶端提供的任何本地狀態。
- （D）客戶端通過包含上一步中收到的授權碼從授權服務器的令牌端點請求訪問令牌。當發起請求時，客戶端與授權服務器進行身份驗證。客戶端包含用於獲得授權碼的重定向URI來用於驗證。
- （E）授權服務器對客戶端進行身份驗證，驗證授權代碼，並確保接收的重定向URI與在步驟（C）中用於重定向（資源所有者的用戶代理）到客戶端的URI相匹配。如果通過，授權服務器響應返回訪問令牌與可選的刷新令牌。
註：上述的應用場景使用了此模式，將在下一篇以示例說明。
OAuth2.0 基礎介紹