OAuth2.0和企業內部統一登陸，token驗證方式，OAuth2.0的 Authorization code grant 和 Implicit grant區別

統一登陸是個不少應用系統都要考慮的問題，多個項目的話最好前期進行統一設計，不然後面改造兼容很麻煩；

• cas認證的方式：新公司都是老項目，用的是cas認證的方式，比較重並且依賴較多，winform的項目也未集成進來，用戶基礎數據如組織機構權限等也未維護進來；其實就是cas登陸後拿到usercode，而後去子系統映射相應usercode的用戶的組織機構，權限信息， 缺點較多，暫不討論；

• token驗證的方式：上家公司採用的方式，用的是基礎數據平臺統一登陸（簡稱登陸服務器），生成token，隨url或者cookie帶入服務端，服務端調用微服務去基礎平臺驗證token有效性及獲取用戶信息；最近研究了下OAuth2.0 , 發現此方式是基本遵循 OAuth2.0 簡化模式（Authorization Grant Implicit），仍是比較好用；  流程大致以下（app1,app2是子系統）：

1. 用戶登陸app1，檢查cookie和url有沒有token信息；假設有，則經過基礎平臺api根據token獲取用戶信息；不然，轉向登陸url；
2. 用戶輸入帳號密碼，登陸服務器生成token返回返回原始url，回到第1步驗證；
3. 應用app1跳轉到app2的時候，url帶上token；app由於是內部系統，因此不作受權管理(好比qq的有應用管理)，全部app共享一個token；
4. token的保存，過時，重複登陸等由登陸服務器統一管理，採用內存服務器redis保證性能；redis key就是token，value是緩存用戶信息，修改後須要從新登陸才生效；
5. 基礎信息如組織機構，權限等，由登陸服務器服務的頁面維護，子系統只查詢，不維護；子系統單據是否冗餘組織機構名稱等信息，仍是隻保存key，自由決定；
6. 登陸服務器全部表只邏輯刪除，數據確保不會丟失；

再說說OAuth2.0, 好比qq，微信，微博等的OAuth平臺，基本是基於OAuth2.0 Authorization code grant模式，先獲取code，再獲取auth token;

OAuth2.0 grant有四種模式，網上介紹也不少，簡單說下：

• Authorization code 受權碼模式：受權後先獲取受權碼code，再根據code獲取token，注意code是不對客戶端開放的，服務端app1能夠經過code任意時間refresh token；各大互聯通平臺基本都是經過此模式寫的開放登陸平臺及api實現；
• Implicit grant 簡化模式： 這個是相對受權碼模式的簡化；簡單說少了一步獲取受權碼code的步驟；直接返回token，RFC6749的解釋是：直接暴漏給客戶端token，能夠由客戶端JS等完成，無需經過app轉接，有必定的風險性；（我的認爲主要就是不能經過受權碼定時刷新token，安全性低）；
• Resource Owner Password Credential 用戶名密碼模式： grant_type=password，直接給app保存用戶名密碼，固然就能夠訪問了，固然安全性最低，密碼多出保存，泄露就一鍋端；
• Client Credential 客戶端模式： grant_type=client_credential， app1和登陸服務器相互信任，客戶端以本身的名義，而不是以用戶的名義，向"服務提供商"進行認證。嚴格地說，客戶端模式並不屬於OAuth框架所要解決的問題。在這種模式中，用戶直接向客戶端註冊，客戶端以本身的名義要求"服務提供商"提供服務，其實不存在受權問題。（沒深研究，我的認爲這已經超脫OAuth須要處理的範疇）

細看一下，「token驗證的方式「就是OAuth2.0的Implicit grant 簡化模式，只不過更精簡：多個子系統app公用一個token，token不綁定app；子系統間的跳轉徹底依賴token的傳遞；權限統一在登陸平臺申請和管理（能夠根據app管理），各個app只負責經過api獲取和權限驗證，更試用於企業內部系統；（好比一個權限名爲「app1的登陸權限」，假設api返回的權限list沒有此權限，則app1直接跳轉到權限不足頁面便可）