01-SSO 業務流程分析
假設，我們有三個系統，分别是單點登入服務（或者也可稱為是統一認證中心、統一認證服務，CAS）、業務系統 A、業務系統 B。
- 場景一，使用者在統一認證中心未登入條件下，首次通路業務系統 A；
- 場景二，使用者在統一認證中心已登入條件下，再次通路業務系統 A；
- 場景三，使用者在統一認證中心已登入條件下，首次通路業務系統 B。
上述三個場景是單點登入模型中的三個典型場景，接下來我将逐個分析，并給出時序圖。
01.1-場景一和場景二
場景一、場景二是關聯性比較強的場景，是以我放在一起讨論。
接下來，我會對圖中流程的關鍵點進行解釋，友善大家了解。 步驟 1-3 是使用者首次通路業務系統 A 時的處理邏輯： A 會先檢查使用者是否登入，如果未登入（從技術上講就是使用者請求中沒有攜帶 Session ID，或攜帶的 Session ID 在目前系統中找不到對應的 Session 對象），會檢查請求是否帶有認證中心頒發的臨時令牌。 由于未在認證中心登入的前提條件，請求中也沒有臨時令牌，是以系統 A 就認為使用者尚未登入，然後會通過重定向的方式告知用戶端去 CAS 進行登入認證（步驟 4）。
步驟 5-7 是認證服務的邏輯，判斷是否登入。判斷方式與前面類似，檢查認證中心系統中是否有使用者對應的 Session 對象。 這裡的 Session 也被稱為全局會話（先記住這個名字），指使用者與認證中心之間建立的會話。 如果使用者未登入，認證中心會提供登入界面讓使用者登入（7-9）。 登入成功後，認證中心會建立一個全局會話，并且生成一個臨時令牌（token），通過重定向響應傳回給使用者（步驟 11）。
使用者拿到統一認證中心的臨時令牌後，會再次請求業務系統 A。 A 會重複使用步驟 1-3 去檢查使用者的請求，發現尚未登入、但是請求中帶有臨時令牌（13-14）。 然後，它會去認證中心校驗令牌的合法性（15-16）。 令牌若合法，系統 A 就知道該使用者在認證中心登入過了，就會建立一個 Session（這個也被稱為是局部會話），并傳回使用者請求的資源（17-18）。
注：從上面的流程中可以發現，全局會話是使用者與認證系統之間的會話，通過登入這種方式建立的。 局部會話是使用者與業務系統之間的，通過校驗臨時令牌的合法性方式建立的。 當全局會話失效，它生成的臨時令牌也将失效，基于臨時令牌的局部會話也将全部失效。 這就是全局會話、局部會話之間的依存關系。
前面的步驟都是在使用者未在 CAS 登入前提下，首次通路業務系統 A 時的處理流程。 接下來，我們來一起看下局部會話建立後，使用者再次通路業務系統 A 時的處理流程。
因為之前已經建立了與業務系統 A 的局部會話，是以再次通路 A，驗證是否已登入時，驗證結果為已登入。 業務系統就會直接傳回使用者請求的資源（步驟 20-21）。
01.2-場景三
場景三也是在場景一的基礎上進行的。 它的流程圖如下所示：
使用者首次通路業務系統 B 時，與場景一中的步驟 1-3 是相同的。 系統 B 發現使用者未登入（不存在使用者、B 之間的局部會話），之後檢查使用者是否帶有臨時令牌。 這裡分為兩種情況：
- 請求裡帶有 token
- 請求裡不帶 token
針對第一中情況，系統 B 會去 CAS 驗證 token 的合法性，若合法，則會建立系統 B 與使用者之間的局部會話，并将使用者請求的資源響應給使用者（步驟 8-14）。
針對第二種情況，系統 B 會重定向使用者請求到 CAS 進行登入。 CAS 收到使用者登入請求後，檢查發現使用者與 CAS 之間已經存在全局會話，則擷取建立全局會話時一并生成的臨時令牌，并通過重定向響應傳回給用戶端。 用戶端收到 token 後，攜帶 token 請求系統 B，與處理第一種情況類似。
02-從 HTTP 封包角度分析 SSO 登入流程
在上一節，我們對 SSO 登入的業務流程進行了梳理，大緻上明白了 SSO 登入在處理什麼問題，處理問題的大緻流程是什麼。 接下來，我将從 HTTP 封包角度，分析一下每個步驟用戶端、業務系統、CAS 認證中心都會接受、發送什麼樣的封包，進而更深入地了解 SSO 登入過程。 同樣地，我會按照上節的三個場景逐個分析。
02.1-場景一和場景二中的 HTTP 封包
步驟一，使用者請求業務系統 A 的某個頁面：
GET /users HTTP/1.1
Host: businessa.example.samson.self
複制代碼 步驟四，業務系統 A 驗證使用者發現未登入，重定向到 CAS 去登入：
HTTP/1.1 302 Moved Temporarily
Location: http://cas.example.samson.self/login?backurl=http://businessa.example.samson.self/users
複制代碼 浏覽器重定向請求，獲得登入界面：
GET /login?backurl=http://businessa.example.samson.self/users HTTP/1.1
Host: cas.example.samson.self
複制代碼 步驟八，使用者送出登入請求後，CAS 驗證并建立全局會話，再将 token 傳回給使用者：
POST /login?backurl=http://businessa.example.samson.self/users HTTP/1.1
Host: cas.example.samson.self
複制代碼 步驟十一，使用者收到重定向響應：
HTTP/1.1 302 Moved Temporarily
Set-Cookie: JSESSIONID=51d5590d-55c0-48cb-bff2-cdab040f687c
Location: http://businessa.example.samson.self/users?authCode=7d227af1-20e5-49bc-829b-b049aaadd56e&username=lihua
複制代碼 步驟十二，帶着令牌通路業務系統 A：
GET /users?authCode=7d227af1-20e5-49bc-829b-b049aaadd56e&username=lihua HTTP/1.1
Host: businessa.example.samson.self
複制代碼 業務系統驗證令牌合法性後，傳回使用者請求的資源（步驟十八）：
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=baf4765d-3d06-4000-aaa1-44fcb9e2b25f
複制代碼 場景二中，使用者已經與業務系統 A 建立好局部會話，是以再次請求時，可以直接獲得資源：
GET /users HTTP/1.1
Host: businessa.example.samson.self
Cookie: JSESSIONID=baf4765d-3d06-4000-aaa1-44fcb9e2b25f
複制代碼 02.2-場景三中的 HTTP 封包
同樣分兩種情況，對于第一種情況，即不帶令牌通路：
GET /permissions HTTP/1.1
Host: businessb.example.samson.self
複制代碼 業務系統發送重定向響應（帶有全局會話 SessionID）：
HTTP/1.1 302 Moved Temporarily
Location: http://cas.example.samson.self/login?backurl=http://businessb.example.samson.self/permissions
Cookie: JSESSIONID=51d5590d-55c0-48cb-bff2-cdab040f687c
複制代碼 CAS 系統傳回響應：
HTTP/1.1 302 Moved Temporarily
Location: http://businessb.example.samson.self/permissions?authCode=7d227af1-20e5-49bc-829b-b049aaadd56e&username=lihua
複制代碼 用戶端帶着令牌通路業務系統 B：
GET /permissions?authCode=7d227af1-20e5-49bc-829b-b049aaadd56e&username=lihua HTTP/1.1
Host: businessb.example.samson.self
複制代碼 業務系統驗證令牌合法性，并建立局部會話：
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=268459a0-3279-4e86-b627-cbe3e3efdf32
複制代碼 針對第 2 種情況，與後面帶着令牌通路系統 B 是一樣的過程。
03-總結
今天，我介紹了 SSO 登入過程的一般流程，并通過三個典型場景分析了登入流程的處理細節。 并且，在了解大緻業務流程後，從 HTTP 封包的角度分析了各個子產品（用戶端、業務系統、統一認證服務）在每個流程中的一般動作。 我隻在分析過程中給出了 HTTP 封包的頭部資訊。 感興趣的小夥伴可以自己動手實作下上述過程，并觀察下整個流程中發送的 HTTP 封包情況，是否跟我介紹的流程一緻。 希望今天的内容能夠對你有所幫助。