OAuth2.0最簡向導（多圖預警）

這個标準比較抽象，使用了很多術語，初學者不容易了解。本文從最小資料單元開始一步一步揭開OAuth 2.0的神秘面紗，希望大家看完本文都能知道OAuth 2.0到底是什麼？

首先，得有一些使用者的資料。

然後，我們需要一個伺服器來管理這些使用者的資料，我們稱之為“資源伺服器”

這時候有個第三方應用想要通路使用者的資料，我們把這第三方應用稱之為“客戶應用”

這時候我們給資源伺服器按個門暴露使用者資料，這個門我們稱之為“API”

客戶應用可以通過API通路使用者的資料，資源伺服器負責傳回使用者資料。

這時候來了個惡意的客戶應用，它也想要擷取使用者資料拿去獲利。由于我們沒給API加上權限校驗，是以惡意的客戶應用也可以擷取使用者資料。

我們迫切需要一種機制來保護使用者資料，業界實踐是提前給客戶應用頒發一個Access Token，它表示客戶應用被授權可以通路使用者資料。

客戶應用請求資源伺服器擷取使用者資料時，在請求裡帶上Access Token 參數，資源伺服器取出請求中的Access Token并校驗Access Token确認客戶應用有通路使用者資料的權限 。

校驗通過後資源伺服器傳回使用者資料

由于該機制工作的前提是：必須提前給客戶應用頒發Access Token，是以這時候我們又需要一個頒發Access Token的角色,我們把這個負責頒發Access Token的角色稱之為授權伺服器。

暫停一下，我們來看看黑闆

• 授權伺服器負責生成Access Token, 并将Access Token 頒發給客戶應用

• 客戶應用帶上Access Token 去通路使用者資料

• 資源伺服器負責從請求裡取出AccessToken，校驗Access Token是否具有通路使用者的權限，如果有則傳回客戶資料。

客戶應用、授權伺服器、資源伺服器之間的關系如下

上面流程中第一步是授權伺服器生成Access Token ,在真實流程中，在頒發Token給客戶應用之前需要先征詢使用者的同意，必須要使用者同意授權才會給客戶應用頒發Access Token。

客戶應用、授權服務、使用者三者之間的互動流程如下：

1. 客戶應用請求授權伺服器擷取Access Token

1. 授權伺服器咨詢使用者意見

1. 使用者同意授權

1. 授權伺服器頒發Access Token 給 客戶應用

OAuth 2.0标準化了Access Token的請求和響應部分，OAuth2.0的細節在RFC 6749（OAuth 2.0授權架構）中描述。

參考網站