OAuth2.0介紹

OAuth2.0是OAuth1.0的延續版本,可是不向後兼任,本文只討論2.0版本.

OAuth是一個開放標準,容許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密的資源,而無需將用戶名和密碼提供給第三方應用.

其實這種場景在如今已經十分廣泛,好比不少論壇,都會開放支持使用QQ登陸,試想若是沒有OAuth,你在碰見這些感興趣的論壇想進行評論發帖時,要麼註冊一個論壇帳號,要麼把你的QQ帳號密碼直接告訴論壇,很顯然前者很繁瑣,後者不安全,而OAuth正是幫你解決這些問題.

OAuth引入了受權層來區分用戶和第三方客戶端,不一樣於用戶直接使用我的密碼憑證,客戶端使用令牌來訪問用戶的私密資源,該令牌包含諸如:範圍,有效期以及其餘的訪問相關屬性.

OAuth定義了四種角色:

1. resource owner(資源全部者):一個容許訪問受保護資源的實體,若是這是一我的,也叫作終端用戶.
2. resource server(資源服務器):這臺服務器承載着受保護的資源,它有能力接收並響應哪些對受保護資源發起的請求.
3. client(客戶端):經過資源全部者和他的受權發起訪問受保護資源的應用
4. authorization server(受權服務器):在成功驗證資源全部者並得到受權後,發送令牌給客戶端

OAuth協議流程:

（A）客戶端請求資源全部者受權(受權請求能夠直接經過資源全部者,更好的方式是使用受權服務器做爲中介).

（B）若資源全部者贊成受權,客戶端會接收到受權許可.

（C）客戶端使用上一步得到的受權許可,向受權服務器申請令牌.

（D）受權服務器對客戶端的受權許可進行驗證,確認無誤後發放令牌.

（E）客戶端使用令牌,向資源服務器申請獲取資源.

（F）資源服務器對令牌進行驗證,確認無誤後贊成向客戶端開放資源.

在上述六個步驟中,第二步客戶端得到受權許但是關鍵步驟,OAuth定義了四中受權方式:

Authorization Code(受權碼模式):

受權碼模式使用受權服務器做爲客戶端和資源全部者的中介,不直接向資源全部者請求受權,而是經過客戶端引導資源全部者到受權服務器(經過用戶代理:如瀏覽器),受權服務器會驗證資源全部者,驗證經過得到受權後,會從新引導資源全部者返回到客戶端頁面,此時,客戶端就能夠獲得受權碼.由於資源全部者僅在受權服務器進行了身份驗證,因此他的憑證不會被客戶端所獲取.受權碼模式提供了很好的安全保障,好比能夠驗證客戶端身份,直接傳輸令牌到客戶端而不須要通過用戶代理從而被暴露給其餘人的可能性.

(A) 客戶端導向資源全部者的用戶代理到受權服務器,在此過程當中會同時傳遞客戶端標識,請求範圍,本地狀態以及一個用於受權服務器回跳的URI.

• response_type:表示受權類型,必選項,此處的值固定爲"code"
• client_id:表示客戶端的ID,必選項
• redirect_uri:表示重定向URI,可選項
• scope:表示申請的權限範圍,可選項
• state:表示客戶端的當前狀態,能夠指定任意值,認證服務器會原封不動地返回這個值.

(B) 受權服務器驗證資源全部者並決定是否贊成客戶端的受權申請.

(C) 假設資源全部者贊成訪問,受權服務器就會重定向用戶代理到客戶端以前指定的回跳地址,並附上一個受權碼.

• code:表示受權碼,必選項.該碼的有效期應該很短,一般設爲10分鐘,客戶端只能使用該碼一次,不然會被受權服務器拒絕.該碼與客戶端ID和重定向URI,是一一對應關係.
• state:若是客戶端的請求中包含這個參數,認證服務器的迴應也必須如出一轍包含這個參數.

(D) 客戶端附上以前得到的受權碼向受權服務器申請令牌,這個請求過程受權服務器將會驗證客戶端身份.

• grant_type:表示使用的受權模式,必選項,此處的值固定爲"authorization_code".
• code:表示上一步得到的受權碼,必選項.
• redirect_uri:表示重定向URI,必選項,且必須與A步驟中的該參數值保持一致.
• client_id:表示客戶端ID,必選項.

(E) 受權服務器驗證客戶端身份,確認受權碼,並確保收到的回跳地址和在C步驟中得一致.若是全都驗證經過,受權服務器返回訪問令牌和更新令牌給客戶端.

• access_token:表示訪問令牌,必選項.
• token_type:表示令牌類型,該值大小寫不敏感,必選項,能夠是bearer類型或mac類型.
• expires_in:表示過時時間,單位爲秒.若是省略該參數,必須其餘方式設置過時時間.
• refresh_token:表示更新令牌,用來獲取下一次的訪問令牌,可選項.
• scope:表示權限範圍,若是與客戶端申請的範圍一致,此項可省略.

Implicit(隱式受權模式):

隱式受權是針對基於瀏覽器實現的使用腳本語言的客戶端的簡化版受權碼流程,它會直接給客戶端分配訪問令牌而不是受權碼.服務器也不回驗證客戶端身份而是經過驗證回跳URL來驗證客戶端ID,而後把令牌傳遞給客戶端.隱式受權模式提升了響應能力和效率,由於它減小了得到令牌的請求次數.然而易用性上升的同時也會在安全性上有所降低,咱們須要權衡利弊.

(A) 客戶端導向資源全部者的用戶代理到受權服務器,在此過程當中會同時傳遞客戶端標識,請求範圍,本地狀態以及一個用於受權服務器回跳的URI.

• response_type：表示受權類型，此處的值固定爲"token"，必選項。
• client_id：表示客戶端的ID，必選項。
• redirect_uri：表示重定向的URI，可選項。
• scope：表示權限範圍，可選項。
• state：表示客戶端的當前狀態，能夠指定任意值，認證服務器會原封不動地返回這個值。

(B) 受權服務器驗證資源全部者並決定是否贊成客戶端的受權申請.

(C) 假設資源全部者贊成訪問,受權服務器就會重定向用戶代理到客戶端以前指定的回跳地址,並附上令牌片斷.

• access_token：表示訪問令牌，必選項。
• token_type：表示令牌類型，該值大小寫不敏感，必選項。
• expires_in：表示過時時間，單位爲秒。若是省略該參數，必須其餘方式設置過時時間。
• scope：表示權限範圍，若是與客戶端申請的範圍一致，此項可省略。
• state：若是客戶端的請求中包含這個參數，認證服務器的迴應也必須如出一轍包含這個參數。

(D) 用戶代理請求客戶端頁面資源(並本地維持片斷信息).

(E) 返回一個包含腳本的頁面,它能夠提取片斷中的令牌信息.

(F) 用戶代理執行本地腳本進而提取令牌.

(G) 用戶代理傳遞令牌給客戶端.

Resource Owner Password Credentials(密碼模式):

密碼模式適用於資源全部者信任高度信任客戶端的場景,例如設備操做系統或者一些特權應用.受權服務器應該只有再沒法執行其餘模式的狀況下才採用該種模式.

(A) 資源全部者提供本身的用戶名和密碼給客戶端.

(B) 客戶端使用得到的憑證向受權服務器申請令牌.

(C) 受權服務器驗證客戶端憑證,若是經過,返回令牌.

• access_token：表示訪問令牌，必選項。
• token_type：表示令牌類型，該值大小寫不敏感，必選項，能夠是bearer類型或mac類型。
• expires_in：表示過時時間，單位爲秒。若是省略該參數，必須其餘方式設置過時時間。
• refresh_token：表示更新令牌，用來獲取下一次的訪問令牌，可選項。
• scope：表示權限範圍，若是與客戶端申請的範圍一致，此項可省略。

Client Credentials(客戶端模式):

客戶端以本身的名義,而不是以資源全部者的名義,向受權服務器進行認證.在這種模式中,用戶直接向客戶端註冊,客戶端以本身的名義要求受權服務器提供服務,其實不存在受權問題.

(A) 客戶端向受權服務器申請令牌.

(B) 資源服務器驗證客戶端,經過後返回令牌.

更新令牌:

當訪問令牌失效過時時,咱們須要使用更新令牌來從新得到訪問令牌.不一樣於訪問令牌,更新令牌永遠都不會被用於資源服務器.

(A) 客戶端向受權服務器請求令牌.

(B) 受權服務器驗證客戶端身份並驗證受權許可,若是經過,返回訪問令牌和更新令牌.

(C) 客戶端使用訪問令牌向資源服務器申請受保護資源.

(D) 資源服務器驗證訪問令牌,若是有效,提供資源服務.

(E) 重複C,D步驟直至訪問令牌失效.

(F) 由於訪問令牌失效,資源服務器返回令牌失效錯誤.

(G) 客戶端使用更新令牌向受權服務器申請新的訪問令牌.

(H) 受權服務器驗證客戶端身份和更新令牌,若是經過,返回一個新的訪問令牌.

 

參考資料地址:

https://tools.ietf.org/html/rfc6749

http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

https://www.cnblogs.com/flashsun/p/7424071.html