統一登錄是個很多應用系統都要考慮的問題，多個項目的話最好前期進行統一設計，否則后面改造兼容很麻煩；
-
cas認證的方式：新公司都是老項目，用的是cas認證的方式，比較重而且依賴較多，winform的項目也未集成進來，用戶基礎數據如組織機構權限等也未維護進來；其實就是cas登錄后拿到usercode，然后去子系統映射相應usercode的用戶的組織機構，權限信息， 缺點較多，暫不討論；
-
token驗證的方式：上家公司采用的方式，用的是基礎數據平台統一登錄（簡稱登錄服務器），生成token，隨url或者cookie帶入服務端，服務端調用微服務去基礎平台驗證token有效性及獲取用戶信息；最近研究了下OAuth2.0 , 發現此方式是基本遵循 OAuth2.0 簡化模式（Authorization Grant Implicit），還是比較好用； 流程大體如下（app1,app2是子系統）：
- 用戶登錄app1，檢查cookie和url有沒有token信息；假設有，則通過基礎平台api根據token獲取用戶信息；否則，轉向登錄url；
- 用戶輸入賬號密碼，登錄服務器生成token返回返回原始url，回到第1步驗證；
- 應用app1跳轉到app2的時候，url帶上token；app因為是內部系統，所以不做授權管理(比如qq的有應用管理)，所有app共享一個token；
- token的保存，過期，重復登錄等由登錄服務器統一管理，采用內存服務器redis保證性能；redis key就是token，value是緩存用戶信息，修改后需要重新登錄才生效；
- 基礎信息如組織機構，權限等，由登錄服務器服務的頁面維護，子系統只查詢，不維護；子系統單據是否冗余組織機構名稱等信息，還是只保存key，自由決定；
- 登錄服務器所有表只邏輯刪除，數據確保不會丟失；
再說說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直接跳轉到權限不足頁面即可）