1、前言
一個安全的信息系統，合法身份檢查是必須環節。尤其IM這種以“人”爲中心的社交體系，身份認證更是必不可少。
一些PC時代小型IM系統中，身份認證可能直接做到長連接中（也就是整個IM系統都是以長連接爲中心：身份鑑權、數據收發、文件傳送等等）。但當前主流的IM（尤其新一代的移動端IM）中，都是“長”（指TCP或UDP長連接）、“短”（是指Http短連接）相結合的方式。
一個現代的移動端IM“長”、“短”連接配合內容大致如下：
1）短連接用途1：前置HTTP的SSO單點接口來實現身份認證；
2）短連接用途2：集羣式的IM中可能還會有獨立（或集成於SSO單獨登陸接口中）的SLB接口（即基於HTTP短連接拉取IM服務器集羣IP列表）；
3）短連接用途3：各種小文件的上傳、下載接口實現（頭像、圖片、語音、文件等）都會是基於Http實現；
4）長連接用途1：用戶的實時上、下線狀態通知；
5）長連接用途2：實時的加友、加羣等指令收發；
6）長連接用途3：服務端發起的其它實時指令推送等。
總之：當今主流的移動IM系統中，“長”、“短”連接分工明確，各自將自身的優勢發揮到最大化，優點是：系統分工明確、分層清晰、業務劃分合理、負載方案成本低、符合移動網絡的特性等。
針對上述主流移動IM系統中“長”、“短”連接的分工方式，其中最爲重要也是用戶最先接觸到的——就是基於Http的SSO單點登陸接口（有的系統裏可能並不叫SSO接口，本文討論的是其廣義：即實現身份認證功能的http接口），那麼這個SSO接口工作原理是什麼？可以怎麼來實現？有無最佳實踐建議？
OK，帶着上述的這幾個疑問，讓我們開啓本文的正文部分。
正文內容說明：正文部分介紹SSO單點登陸接口時，是以通用信息系統的角度來闡述原理、邏輯、最佳實踐，而非專門針對IM系統，但道理是一模一樣的，理解原理後完全可以設計出適合您IM系統的SSO接口。（話外音：其實是懶的重新打字和畫圖 ^_^）。
學習交流：
- 即時通訊開發交流羣：320837163 [推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發佈於：http://www.52im.net/thread-1351-1-1.html）
2、相關文章
▼ 帶着本文對SSO單點登陸（或者說身份認證）接口的知識，您將能更好的讀懂下述技術文章：
總之，以上幾篇精選的文章可以跟本文的知識相輔相成，共同完善您的IM技術開發知識體系，希望對你有用。
▼ IM開發乾貨系列文章也適合作爲IM開發的系統性入門資料（本文是其第10篇）：
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
如果您正在查閱更多移動端IM開發資料，強烈推薦閱讀《新手入門一篇就夠：從零開發移動端IM》。
3、原作者
楊麗：擁有多年互聯網應用系統研發經驗，曾就職於古大集團，現任職中青易遊的系統架構師，主要負責公司研發中心業務系統的架構設計以及新技術積累和培訓。現階段主要關注開源軟件、軟件架構、微服務以及大數據。
張輝清：10 多年的 IT 老兵，先後擔任攜程架構師、古大集團首席架構、中青易遊 CTO 等職務，主導過兩家公司的技術架構升級改造工作。現關注架構與工程效率，技術與業務的匹配與融合，技術價值與創新。
4、單點登錄原理簡介
假設一個場景：公司內部有財務、OA、訂單服務等各類相互獨立的應用系統，員工張三對這些系統有操作權限，如果張三想要登錄某個系統進行業務操作，那麼他需要輸入相應的賬號與密碼。
想象一下：當公司內部有 100 個應用系統，張三是不是要輸入 100 次用戶名和密碼進行登錄，然後分別才能進行業務操作呢？顯然這是很不好的體驗。
因此我們需要引入一個這樣的機制：張三隻要輸入一次用戶名和密碼登錄，成功登錄後，他就可以訪問財務系統、OA 系統、訂單服務等系統——這就是單點登錄。
單點登錄的英文全稱是 Single Sign On，簡稱是 SSO：
它的意思是說用戶只需要登錄一次，就可以在個人權限範圍內，訪問所有相互信任應用的功能模塊，不管整個應用羣的內部有多麼複雜，對用戶而言，都是一個統一的整體。用戶訪問 Web 系統的整個應用羣與訪問單個系統一樣，登錄和註銷分別只要一次就夠了。
舉個簡單的例子，你登錄了百度網頁之後，點擊跳轉到百度貼吧，這時可以發現你已經自動登錄了百度貼吧——這就是單獨登陸的原理。
5、理論聯繫實際來講解SSO單點登陸技術實現
5.1 基本介紹
針對本文上半部分的原理介紹，我們以一個真實的信息系統爲例，理論聯繫實際來講解具體的SSO單點登陸技術實現（實際上，用IM系統的設計思路來看這個例子，可能有點複雜，但知識是相通的，它更有助於對SSO完整知識體系的理解。）
SSO 的技術實現要想做好並不容易，作者認爲需求優先級應該先是單點登錄和單點註銷功能，然後是應用接入的門檻，最後是數據安全性，安全性對於 SSO 也非常重要。SSO 的核心是認證中心，但要實現用戶一次登錄，到處訪問的效果，技術實現需要建立在用戶系統、認證中心、權限系統、企業門戶的基礎上。
各職責如下：
用戶系統：負責用戶名、密碼等帳戶信息管理，包括增加、修改、啓用、停用用戶帳號，同時爲認證中心提供對用戶名和密碼的校驗；
認證中心：負責憑證 token 的生成、加密、頒發、驗證、銷燬、登入 Login、登出 Logout。用戶只有擁有憑證並驗證通過才能訪問企業門戶；
權限系統：負責角色管理、資源設置、授權設置、鑑定權限，具體實現可參考 RBAC。權限系統可爲企業門戶提供用戶權限範圍內的導航；
企業門戶：作爲應用系統的集成門戶 (Portal)，集成了多個應用系統的功能，爲用戶提供鏈接導航、用戶信息和登出功能等。
5.2 服務端功能實現
主要包含以下內容：
登錄認證：接收登錄帳號信息，讓用戶系統驗證用戶的登錄信息；
憑證生成：創建授權憑證 token，生成的憑證一般包含用戶帳號信息、過期時間等信息，它是一串加密的字符串，加密算法如 AES｛憑證明文 +MD5 加信息｝，可採用 JWT 標準；
憑證頒發：與 SSO 客戶端通信，發送憑證給 SSO 客戶端；
憑證驗證：接收並校驗來自 SSO 客戶端的憑證有效性，憑證驗證包括算法驗證和數據驗證；
憑證銷燬與登出：接收來自 SSO 客戶端的登出請求，記錄並銷燬憑證，跳轉至登錄頁面。
5.3 客戶端功能實現
客戶端的實現邏輯大致如下：
1）請求攔截：攔截應用未登錄請求，跳轉至登錄頁面；
2）獲取憑證：接收並存儲由 SSO 服務端發來的憑證，憑證存儲的方式有 Cookie、Session、網址傳參、Header 等；
3）提交憑證驗證：與 SSO 服務端通信，發出校驗憑證有效性的請求；
4）獲取用戶權限：獲取該憑證的用戶權限，並返回受保護資源給用戶；
5）憑證銷燬與登出：銷燬本地會話，然後跳轉至登出頁面。
5.4 用戶單點登錄流程
用戶的單點登錄流程如下：
1）登錄：將用戶輸入的用戶名和密碼發送至認證中心，然後認證中心調用用戶系統來驗證登錄信息；
2）生成並頒發憑證：通過登錄信息的驗證後，認證中心創建授權憑證 token，然後把這個授權憑證 token 返回給 SSO 客戶端。SSO 客戶端拿到這個 token，進行存儲。在後續請求中，在 HTTP 請求數據中都得加上這個 token；
3）憑證驗證：SSO 客戶端發送憑證 token 給認證中心，認證中心校驗這個 token 的有效性。憑證驗證有算法驗證和數據驗證，算法驗證可在 SSO 客戶端完成。
5.5 用戶訪問流程和單點註銷
以上是用戶的訪問流程，如果用戶沒有有效的憑證，認證中心將強制用戶進入登錄流程。對於單點註銷，用戶如果註銷了應用羣內的其中一個應用，那麼全局 token 也會被銷燬，應用羣內的所有應用將不能再被訪問。
5.6 具體接入與集成
例子中的應用接入與集成具體如下：
1）用戶系統：接入國內機票平臺的用戶系統，負責登錄認證；
2）權限系統：接入國內機票平臺的權限系統；
3）認證中心：負責生成並頒發憑證、銷燬憑證，改造國內機票平臺的登入、登出；
4）憑證驗證：在國內機票、國際機票應用系統中調用 SSO 客戶端組件實現憑證的驗證；
5）企業門戶：由國內機票平臺、國際機票平臺承擔。
6、附加知識：一項被稱爲JWT的技術
JSON Web Token (JWT) 是目前應用最爲廣泛的 token 格式，是爲了在網絡應用環境間傳遞聲明而執行的一種基於 JSON 的開放標準（RFC 7519)。該 token 設計緊湊且安全，特別適用於分佈式站點的單點登錄、API 網關等場景。
JWT 的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源服務器獲取資源，也可以增加一些額外的其它業務邏輯所必須的聲明信息。該 token 也可直接被用於認證，也可被加密。JWT 信息體由 3 部分構成：頭 Header+ 載荷 Payload+ 簽名 Signature。
JWT具體優點如下：
JWT 支持多種語言，C#、Java、JavaScript、Node.js、PHP 等很多語言都可以使用；
JWT 可以自身存儲一些和業務邏輯有關的所必要的非敏感信息，因爲有了 Payload 部分；
利於傳輸，因爲 JWT 的構成非常簡單，字節佔用很小；
不需要在服務端保存會話信息，不僅省去服務端資源開銷，而且使得應用易於擴展。
（本文同步發佈於：http://www.52im.net/thread-1351-1-1.html）
附錄：更多IM開發技術文章
[1] 有關IM架構設計：
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
>> 更多同類文章 ……
[2] 有關IM安全的文章：
《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風險》
《即時通訊安全篇（五）：對稱加密技術在Android平臺上的應用實踐》
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯繫實際：一套典型的IM通信協議設計詳解（含安全層設計）》
《微信新一代通信安全解決方案：基於TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》
《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
>> 更多同類文章 ……
[3] IM開發綜合文章：
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
《開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《基於社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的？》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-1351-1-1.html）