IM开发基础知识补课：正确理解前置HTTP SSO单点登陆接口的原理
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 開發中登錄請求的優化》
《移動端IM登錄時拉取數據如何作到省流量？》
《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》
總之，以上幾篇精選的文章可以跟本文的知識相輔相成，共同完善您的IM技術開發知識體系，希望對你有用。
▼?IM開發干貨系列文章也適合作為IM開發的系統性入門資料（本文是其第10篇）：
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的“時序性”與“一致性”？》
《IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”？》
《IM群聊消息如此復雜，如何保證不丟不重？》
《一種Android端IM智能心跳算法的設計與實現探討（含樣例代碼）》
《移動端IM登錄時拉取數據如何作到省流量？》
《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》
《淺談移動端IM的多點登陸和消息漫游原理》
《IM開發基礎知識補課：正確理解前置HTTP SSO單點登陸接口的原理》（本文）
如果您正在查閱更多移動端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系統的架構設計》
《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《一套原創分布式即時通訊(IM)系統理論架構方案》
《從零到卓越：京東客服即時通訊系統的技術架構演進歷程》
《蘑菇街即時通訊/IM服務器開發之架構選擇》
《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》
《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《17年的實踐：騰訊海量產品的技術方法論》
《移動端IM中大規模群消息的推送如何保證效率、實時性？》
《現代IM系統中聊天消息的同步和存儲方案探討》
>>?更多同類文章 ……
[2] 有關IM安全的文章：
《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
《即時通訊安全篇（二）：探討組合加密算法在IM中的應用》
《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》
《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風險》
《即時通訊安全篇（五）：對稱加密技術在Android平臺上的應用實踐》
《即時通訊安全篇（六）：非對稱加密技術的原理與應用實踐》
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯系實際：一套典型的IM通信協議設計詳解（含安全層設計）》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端安全通信的利器——端到端加密（E2EE）技術詳解》
《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《通俗易懂：一篇掌握即時通訊的消息傳輸安全原理》
>>?更多同類文章 ……
[3] IM開發綜合文章：
《移動端IM中大規模群消息的推送如何保證效率、實時性？》
《移動端IM開發需要面對的技術問題》
《開發IM是自己設計協議用字節流好還是字符流好？》
《請問有人知道語音留言聊天的主流實現方式嗎？》
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的“時序性”與“一致性”？》
《一個低成本確保IM消息時序的方法探討》
《IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”？》
《IM群聊消息如此復雜，如何保證不丟不重？》
《談談移動端 IM 開發中登錄請求的優化》
《移動端IM登錄時拉取數據如何作到省流量？》
《淺談移動端IM的多點登陸和消息漫游原理》
《完全自已開發的IM該如何設計“失敗重試”機制？》
《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》
《微信對網絡影響的技術試驗及分析（論文全文）》
《即時通訊系統的原理、技術和應用（技術論文）》
《開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《基于社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的？》
>>?更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-1351-1-1.html）
總結
以上是生活随笔為你收集整理的IM开发基础知识补课：正确理解前置HTTP SSO单点登陆接口的原理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： svn 修改文件的二进制或文本标记
- 下一篇： kali操作系统SSH问题解决方案