OAuth2.0 基礎介紹

一、應用場景

二、角色說明

三、OAuth2.0 概述

四、協議流程

五、四種受權模式

六、受權碼模式

應用場景

這裏以「簡書」爲例，網友但願在簡書的文章下留言，但須要先登陸。在登陸頁面，提供多種方式登陸，例如：微博、微信、QQ帳戶等。減小了網友註冊並管理多個帳戶的麻煩。但簡書如何使用微博登陸，獲取用戶信息並確保其數據不被泄露，這時 OAuth2.0 派上用場。

角色說明

一、Resource Owner

資源擁有者，可以許可對受保護資源的訪問權限的實體。當資源全部者是我的時，它被稱爲最終用戶。
二、Resource Server

資源服務器，管理受保護資源的服務器，可以接收和響應使用訪問令牌對受保護資源的請求。例如，微博的資源服務器。
三、Client                

第三方應用客戶端，資源擁有者發起對受保護資源的請求的應用程序。例如：簡書。
四、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相匹配。若是經過，受權服務器響應返回訪問令牌與可選的刷新令牌。

注：上述的應用場景使用了此模式，將在下一篇以示例說明。