OAuth2.0認證受權workflow

在設計一個系統的時候大多數都須要一個登錄受權的方案來保證訪問安全和權限的控制。好在咱們有相似於spring這樣的框架，更多的時候只須要完成幾行配置就能工做。這也讓開發者忽略了他的工做流程和原理,就經過這篇文章來認識探討下。首先拋出一個概念：SSO單點登陸（Single Sign On）。

SSO&CAS

其定義爲：

SSO是在多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。它包括能夠將此次主要的登陸映射到其餘應用中用於同一個用戶的登陸的機制。它是目前比較流行的企業業務整合的解決方案之一。

SSO這是一個概念方案，其中有咱們常常聽到的著名的耶魯大學的CAS系統就是它的一個實現。具體能夠了解 CAS Architecture，其工程流程圖以下：

其中核心要解決的的是引入鑑權和認證的流程，實現多套系統的單一訪問須要的是同一套受權方案便可。

鑑權和認證

認證(Authentication)和受權（Authorization）老是成對出現，可是不能混爲一談。

簡單的來講，認證是用來肯定小明是否是真的小明的。受權是限定小明具有哪些權限的，好比小明只能夠看這篇博客不能修改這篇博客，而我做者本人能夠。

那麼這個流程應該是怎麼樣的呢，每家的方案不能總不同吧，那麼就出現了這樣一個標準:OAuth,如今已經出到2.0了，也就是咱們今天要了解的OAuth 2.0.因此

OAuth2.0是行業標準的受權(Authentication)協議.

OAuth 2.0關注客戶端開發者的簡易性，同時爲Web應用，桌面應用和手機，和起居室設備提供專門的認證流程。

來看官方的工做流描述：

+--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+
複製代碼

Abstract Protocol Flow，好吧，是挺抽象，尤爲是Autorization Grant是怎麼完成的咱們仍是不得而知。不過咱們能夠得知想要訪問資源服務，咱們最終是拿到受權服務分配的Access Token，OAuth 2.0的受權模式有好幾種，主要仍是根據設計的需求。咱們就拿最複雜和最完善的一個模式來分析：受權碼模式。一樣，咱們先看官方的解釋：

+----------+
 | Resource |
 |   Owner  |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier      +---------------+
 |         -+----(A)-- & Redirection URI ---->|               |
 |  User-   |                                 | Authorization |
 |  Agent  -+----(B)-- User authenticates --->|     Server    |
 |          |                                 |               |
 |         -+----(C)-- Authorization Code ---<|               |
 +-|----|---+                                 +---------------+
   |    |                                         ^      v
  (A)  (C)                                        |      |
   |    |                                         |      |
   ^    v                                         |      |
 +---------+                                      |      |
 |         |>---(D)-- Authorization Code ---------'      |
 |  Client |          & Redirection URI                  |
 |         |                                             |
 |         |<---(E)----- Access Token -------------------'
 +---------+       (w/ Optional Refresh Token)
複製代碼

從圖中咱們能夠看出大概的流程，用戶訪問資源的時候首先要通過受權服務的受權，訪問受權服務的過程用戶經過客戶代理帶上註冊好的Clent ID 和重定向的地址，受權服務驗證好是否正確以後會給到客戶代理一個受權碼，把受權碼帶給客戶端，客戶端能夠經過此受權碼才能獲取可訪問的Access Token。前面有總結過，只有拿到有效的Access Token才能暢通的訪問到咱們的資源服務。

不過...爲何要這麼複雜？爲何不一步到位第一次訪受權服務的時候（User authenticates）就拿到Access Token,而須要經過受權碼去拿到Access Token？

答案是：爲了安全

首先這裏須要此類受權碼的狀況只成立因而並無使用Https去訪問，比我相似於窮x的博主買不起ssl認證服務。由於問題可能出如今給到client端Access Token的方式有關，若是直接藉助的重定向返回AccessToken,這就給了Hacker劫持到Access Token的機會，由於uri可能經過HTTP referrer被傳遞給其它惡意站點，也可能存在於瀏覽器cacher或log文件中。可是直接重定向返回Authorization Code就不是什麼敏感的數據了，經過Authorization Code再從新校驗去獲取Access Token的時候須要上傳Client密鑰（僅client持有），擁有有效Client Secret 的訪問才能被保證是安全的。

若是你不是相似於博主這樣的窮x,官方推薦也是implicit flow模式，更加快捷安全。

以上，基本上清楚了OAuth2的流程，恰巧勤勞的大神麼也會有些不錯的實現代碼供你們參考，這裏蒐羅了一個不錯的實現案例：oltu-oauth2-example

結合的畫一個流程圖幫助理解：

重要流程列表

• 註冊應用：獲取client_id，client_secret。
• 請求受權碼：經過client_id獲取受權碼auth_code
• 換取accessToken：經過client_id，client_secret，auth_code獲取AccessToken
• 經過AccessToken訪問資源服務

其中請求受權的過程須要打開登錄頁面，輸入用戶名密碼正確以後再返回auth_code。