單點登錄-SSO原理

為什么需要單點登錄

單點登錄SSO（Single Sign On）說得簡單點就是在一個多系統共存的環境下，用戶在一處登錄后，就不用在其他系統中登錄，也就是用戶的一次登錄能得到其他所有系統的信任。

單點登錄在大型網站里使用得非常頻繁，例如，阿里旗下有淘寶、天貓等網站，還有背后的成百上千的子系統，用戶一次操作或交易可能涉及到幾十個子系統的協作，如果每個子系統都需要用戶認證，不僅用戶會瘋掉，各子系統也會為這種重復認證授權的邏輯搞瘋掉。

所以，單點登錄要解決的就是，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。

單點登錄的來源

1.早期web單系統應用

早期我們開發web應用都是所有的包放在一起打成一個war包放入tomcat容器來運行的,所有的功能,所有的業務,后台管理,門戶界面,都是由這一個war來支持的,這樣的單應用,也稱之為巨石應用,因為十分不好擴展和拆分。

在巨石應用下，用戶的登錄以及權限就顯得十分簡單，當瀏覽器向服務器發送登錄請求時，驗證通過之后，會將用戶信息存入seesion中，然后服務器會生成一個sessionId放入cookie中，隨后返回給瀏覽器。

大致可以用下圖來表示:

驗證登錄的這個會話就是session,維護了用戶狀態,也就是所謂的HTTP有狀態協議,我們經常可以在瀏覽器中看到JSESSIONID,這個就是用來維持這個關系的key。

2.分布式集群部署

由於網站的訪問量越來也大，單機部署已經是巨大瓶頸，所以才有了后來的分布式集群部署。

例如：如果引入集群的概念,單應用可能重新部署在3台tomcat以上服務器,使用nginx來實現反向代理。

但是增加新的服務器之后，不同的服務器之間的sessionId是不一樣的，可能在A服務器上已經登錄成功了，能從服務器的session中獲取用戶信息，但是在B服務器上卻查不到session信息，只好退出來繼續登錄，結果A服務器中的session因為超時失效，登錄之后又被強制退出來要求重新登錄。

所以不得不考慮多服務器之間的session數據一致的問題，這就是單點登錄的最早來源。

單點登錄的實現方式

單點登錄的本質就是在多個應用系統中共享登錄狀態，如果用戶的登錄狀態是記錄在 Session 中的，要實現共享登錄狀態，就要先共享 Session。

所以實現單點登錄的關鍵在於，如何讓 Session ID（或 Token）在多個域中共享。

1.同域下的單點登錄

一個企業一般情況下只有一個域名，通過二級域名區分不同的系統。

比如我有個域名：mikechen.cc，同時有兩個業務系統分別為：

1. blog.mikechen.cc
2. video.mikechen.cc

我們要做單點登錄（SSO），需要一個登錄系統，叫做：sso.mikechen.cc。

我們只要在sso.mikechen.cc登錄，blog.mikechen.cc和video.mikechen.cc也登錄了。

實現方式：其實這里就是利用了 二級域名 寫 一級域名的 Cookie 。sso.mikechen.cc登錄以后，可以將Cookie的域設置為頂域，即.mikechen.cc，這樣所有子域blog.mikechen.cc和video.mikechen.cc的系統都可以訪問到頂域的Cookie。

此種實現方式比較簡單，但不支持跨主域名,局限性限於一級域名是一樣的。

2.不同域下的單點登錄

同域下的單點登錄是巧用了Cookie頂域的特性,如果是不同域呢，比如：下面三個是不同域的

1. mikechen1.cc
2. mikechen2.cc
3. mikechen3.cc

實現方式：我們可以部署一個SSO認證中心,認證中心就是一個專門負責處理登錄請求。

所有的請求（登錄、退出、獲取用戶信息、當前用戶狀態）都請求sso 系統，sso 系統維護用戶信息。

此種實現方式相對復雜，支持跨域，擴展性好，是單點登錄的標准做法。

基於SSO認證中心的開源項目代表:CAS，其中 CAS是Central Authentication Service，即中央認證服務，下圖是CAS的基本過程：

簡介和區別
SSO, single sign on,單點登錄。sso多用於多個應用之間的切換，例如百度論壇、百度知道、百度雲、百度文庫等，在其中一個系統中登錄， 切換到另一個系統的時候，不必再次輸入用戶名密碼。
oauth2.0，開放授權，不兼容oauth1.0.允許第三方應用代表用戶獲得訪問權限。可以作為web應用、桌面應用和手機等設備提供專門的認證流程。例如，用qq賬號登錄豆瓣、美團、大眾點評；用支付寶賬號登錄淘寶、天貓等。
區別：sso和oauth2.0在應用場景上的區別在於，SSO是為了解決一個用戶在鑒權服務器登陸過一次以后，可以在任何應用（通常是一個廠家的各個系統）中暢通無阻。OAuth2.0解決的是通過令牌（token）而不是密碼獲取某個系統的操作權限（不同廠家之間的賬號共享）。
SSO
傳統的多應用切換，面臨 cookie 跨域和session共享的問題，只要解決了上面兩塊問題都可以是實現SSO。
下面介紹了一種單點登錄的方式CAS(中央認證服務Central Authentication Service)。
CAS介紹
2012年，Jasig和另一個有影響的組織Sakai Foundation合並，組成Apereo。Apereo是一個由高等學術教育機構發起組織的聯盟，旨在為學術教育機構提供高質量軟件，當然很多軟件也被大量應用於商業環境，譬如CAS。目前CAS由Apereo社區維護。
CAS的官方網址是： https://www.apereo.org/projects/cas
Github地址：https://github.com/apereo/cas

主要特征：

CAS服務是保障各業務系統的用戶資源的安全 。
各個業務系統獲得的信息是，這個用戶能不能訪問我的資源。
單點登錄，資源都在各個業務系統這邊，不在CAS服務那一方。 用戶在給CAS服務器提供了用戶名密碼后，作為業務系統並不知道這件事。CAS隨便給業務系統一個ST，那么業務系統是不能確定這個ST是用戶偽造的，還是真的有效，所以要拿着這個ST去CAS服務器再問一下，這個用戶給我的ST是否有效，是有效的我才能讓這個用戶訪問。

上圖是CAS官網上的標准流程，具體流程如下：

用戶訪問app系統，app系統是需要登錄的，但用戶現在沒有登錄。
跳轉到CAS server，即SSO登錄系統，以后圖中的CAS Server我們統一叫做SSO系統。SSO系統也沒有登錄，彈出用戶登錄頁。
用戶填寫用戶名、密碼，SSO系統進行認證后，將登錄狀態寫入SSO的session，瀏覽器（Browser）中寫入SSO域下的Cookie。
SSO系統登錄完成后會生成一個ST（Service Ticket），然后跳轉到app系統，同時將ST作為參數傳遞給app系統。
app系統拿到ST后，從后台向SSO發送請求，驗證ST是否有效。
驗證通過后，app系統將登錄狀態寫入session並設置app域下的Cookie。
至此，跨域單點登錄就完成了。以后我們再訪問app系統時，app就是登錄的。接下來，我們再看看訪問app2系統時的流程。

用戶訪問app2系統，app2系統沒有登錄，跳轉到SSO。
由於SSO已經登錄了，不需要重新登錄認證。
SSO生成ST，瀏覽器跳轉到app2系統，並將ST作為參數傳遞給app2。
app2拿到ST，后台訪問SSO，驗證ST是否有效。
驗證成功后，app2將登錄狀態寫入session，並在app2域下寫入Cookie。
這樣，app2系統不需要走登錄流程，就已經是登錄了。SSO，app和app2在不同的域，它們之間的session不共享也是沒問題的。

302 表示臨時性重定向。訪問一個Url時，被重定向到另一個url上，常用於頁面跳轉。

oauth2.0
OAuth2 RFC6749中文翻譯：http://colobu.com/2017/04/28/oauth2-rfc6749/

OAuth 2.0授權框架支持第三方支持訪問有限的HTTP服務，通過在資源所有者和HTTP服務之間進行一個批准交互來代表資源者去訪問這些資源，或者通過允許第三方應用程序以自己的名義獲取訪問權限。

為了方便理解，可以想象OAuth2.0就是在用戶資源和第三方應用之間的一個中間層，它把資源和第三方應用隔開，使得第三方應用無法直接訪問資源，從而起到保護資源的作用。

為了訪問這種受保護的資源，第三方應用（客戶端）在訪問的時候需要提供憑證。即，需要告訴OAuth2.0你是誰你要做什么。

你可以將用戶名和密碼告訴第三方應用，讓第三方應用直接以你的名義去訪問，也可以授權第三方應用去訪問。

可以聯想一下微信公眾平台開發，在微信公眾平台開發過程中當我們訪問某個頁面，頁面可能彈出一個提示框應用需要獲取我們的個人信息問是否允許，點確認其實就是授權第三方應用獲取我們在微信公眾平台的個人信息。這里微信網頁授權就是使用的OAuth2.0。

OAuth定義了四種角色：

resource owner（資源所有者）
resource server（資源服務器）
client（客戶端）：代表資源所有者並且經過所有者授權去訪問受保護的資源的應用程序
authorization server（授權服務器）：在成功驗證資源所有者並獲得授權后向客戶端發出訪問令牌
授權類型有四種：authorization code, implicit, resource owner password credentials, and client credentials

————————————————

一、前言

介紹了一下SSO的概念及原理，然后使用SpringBoot+Redis實現了一個簡單的SSO系統。系統使用ticket的形式，依靠cookie攜帶ticket向sso服務器進行驗證，驗證通過后允許訪問請求地址。

二、SSO介紹

SSO(Single Sign On)，單點登錄，簡單來說就是在一個具有多個子系統的系統中，只用登錄一個子系統，然后訪問其他子系統時不需要再次登錄，即“一次登錄，多處訪問”，能夠有效的提升用戶體驗。

單點登錄的大致流程如下（基於cookie）：

1.用戶首次訪問A系統，A系統發現用戶未登錄，則重定向到SSO認證中心並攜帶請求url，進行登錄驗證；

2.用戶在SSO認證中心進行用戶名和密碼驗證登錄，登錄成功后，服務器生成一個ticket，然后重定向到系統A的源url並將該ticket追加到url參數。

3.系統A獲取到url參數中的ticket，向SSO發起ticket較驗，較驗成功，則系統A放行，並將ticket存入到cookie。

4.用戶訪問B系統，此時B系統domain下已經攜帶ticket，直接向SSO發起ticket較驗，較驗成功，則放行，並將ticket存入cookie(更新ticket過期時間)

5.用戶登出時，移除domain下的cookie。

 

三、基於SpringBoot和Redis實現

系統結構

 

 

實現原理

原理較為簡單，采用共享cookie實現SSO，sso-server使用redis存儲用戶ticket，app-a和app-b使用Spring攔截器過濾用戶請求，每個請求都需要向sso-server驗證ticket,若驗證失敗則重定向到登錄(附帶源url).

系統特點

使用一種一次性的ticket，即一個ticket只能使用一次，用過之后立馬失效，來保證ticket的安全性。

四、問題與思考

1.使用cookie還是url?

對於ticket的傳輸，一直在糾結使用cookie還是url附加參數的形式，最后處於方便考慮，還是使用了cookie。

2.如何保證ticket的安全性？

這個問題也困擾了我一下午，一直在尋求一種完美的、安全的ticket傳遞形式，最后明白了，在網絡上沒有絕對的安全，當破解它所帶來的利益小於破解后所帶來的利益時，他就是安全的，即安全是相對的。所以既然ticket是作為cookie或者url參數傳遞的，那么它的安全性本來就沒有保證，我們能保證的是如何對ticket進行較驗，如何驗證拿到同一個ticket的用戶是同一個用戶。對於這個問題，我使用了一種一次性的ticket，上邊也說了，這樣雖然不能保證絕對的安全，但是在某種程度上能夠有效防止他人直接截獲cookie而獲得權限。

3.關於cookie的domian

在測試過程中發現cookie寫入的都是二級域名，例如aa.test.com而不是test.com，這導致其他系統無法共享cookie而導致單點登錄失敗，解決辦法是直接設置domain為.test.com即可，注意前面的點不能省略。其次直接在yml里使用如下配置設置cookie的domain是無效的

server:
	servlet:
	    session:
	      cookie:
	        domain: .test.com

4.登出時直接請求sso-server還是請求子系統？

考慮到是子系統之間共享的cookie，所以清除子系統的cookie即可。

五、單點登錄和單點登出演示

所用測域名：

#對應app-a，端口為8081 127.0.0.1 aa.test.com

#對應app-b,端口為8082 127.0.0.1 aa.test.com

#對應sso-server,端口為8080 127.0.0.1 sso.com

1.首先啟動這三個項目，並啟動redis

2.然后訪問app-a的home頁面(http://aa.test.com/home)，因為未登錄所以跳轉到sso的登錄頁面;

3.登錄成功后自動返回app-a的home界面，此時再次訪問app-b的home界面則不需要再次登錄

4.在app-b的Home界面退出登錄，再訪問app-a的home界面，則要求重新登錄

如何實現sso單點登錄的原理詳解

一、單系統登錄機制

1、http無狀態協議

　　web應用采用browser/server架構，http作為通信協議。http是無狀態協議，瀏覽器的每一次請求，服務器會獨立處理，不與之前或之后的請求產生關聯，這個過程用下圖說明，三次請求/響應對之間沒有任何聯系

　　但這也同時意味着，任何用戶都能通過瀏覽器訪問服務器資源，如果想保護服務器的某些資源，必須限制瀏覽器請求；要限制瀏覽器請求，必須鑒別瀏覽器請求，響應合法請求，忽略非法請求；要鑒別瀏覽器請求，必須清楚瀏覽器請求狀態。既然http協議無狀態，那就讓服務器和瀏覽器共同維護一個狀態吧！這就是會話機制

2、會話機制

　　瀏覽器第一次請求服務器，服務器創建一個會話，並將會話的id作為響應的一部分發送給瀏覽器，瀏覽器存儲會話id，並在后續第二次和第三次請求中帶上會話id，服務器取得請求中的會話id就知道是不是同一個用戶了，這個過程用下圖說明，后續請求與第一次請求產生了關聯

　　服務器在內存中保存會話對象，瀏覽器怎么保存會話id呢？你可能會想到兩種方式

1. 請求參數
2. cookie

　　將會話id作為每一個請求的參數，服務器接收請求自然能解析參數獲得會話id，並借此判斷是否來自同一會話，很明顯，這種方式不靠譜。那就瀏覽器自己來維護這個會話id吧，每次發送http請求時瀏覽器自動發送會話id，cookie機制正好用來做這件事。cookie是瀏覽器用來存儲少量數據的一種機制，數據以”key/value“形式存儲，瀏覽器發送http請求時自動附帶cookie信息

　　tomcat會話機制當然也實現了cookie，訪問tomcat服務器時，瀏覽器中可以看到一個名為“JSESSIONID”的cookie，這就是tomcat會話機制維護的會話id，使用了cookie的請求響應過程如下圖

3、登錄狀態

　　有了會話機制，登錄狀態就好明白了，我們假設瀏覽器第一次請求服務器需要輸入用戶名與密碼驗證身份，服務器拿到用戶名密碼去數據庫比對，正確的話說明當前持有這個會話的用戶是合法用戶，應該將這個會話標記為“已授權”或者“已登錄”等等之類的狀態，既然是會話的狀態，自然要保存在會話對象中，tomcat在會話對象中設置登錄狀態如下

1 2	HttpSession session = request.getSession(); session.setAttribute( "isLogin" ,  true );

　　用戶再次訪問時，tomcat在會話對象中查看登錄狀態

1 2	HttpSession session = request.getSession(); session.getAttribute( "isLogin" );

　　實現了登錄狀態的瀏覽器請求服務器模型如下圖描述

　　每次請求受保護資源時都會檢查會話對象中的登錄狀態，只有 isLogin=true 的會話才能訪問，登錄機制因此而實現。

二、多系統的復雜性

　　web系統早已從久遠的單系統發展成為如今由多系統組成的應用群，面對如此眾多的系統，用戶難道要一個一個登錄、然后一個一個注銷嗎？就像下圖描述的這樣

　　web系統由單系統發展成多系統組成的應用群，復雜性應該由系統內部承擔，而不是用戶。無論web系統內部多么復雜，對用戶而言，都是一個統一的整體，也就是說，用戶訪問web系統的整個應用群與訪問單個系統一樣，登錄/注銷只要一次就夠了

　　雖然單系統的登錄解決方案很完美，但對於多系統應用群已經不再適用了，為什么呢？

　　單系統登錄解決方案的核心是cookie，cookie攜帶會話id在瀏覽器與服務器之間維護會話狀態。但cookie是有限制的，這個限制就是cookie的域（通常對應網站的域名），瀏覽器發送http請求時會自動攜帶與該域匹配的cookie，而不是所有cookie

　　既然這樣，為什么不將web應用群中所有子系統的域名統一在一個頂級域名下，例如“*.baidu.com”，然后將它們的cookie域設置為“baidu.com”，這種做法理論上是可以的，甚至早期很多多系統登錄就采用這種同域名共享cookie的方式。

　　然而，可行並不代表好，共享cookie的方式存在眾多局限。首先，應用群域名得統一；其次，應用群各系統使用的技術（至少是web服務器）要相同，不然cookie的key值（tomcat為JSESSIONID）不同，無法維持會話，共享cookie的方式是無法實現跨語言技術平台登錄的，比如java、php、.net系統之間；第三，cookie本身不安全。

　　因此，我們需要一種全新的登錄方式來實現多系統應用群的登錄，這就是單點登錄

三、單點登錄

　　什么是單點登錄？單點登錄全稱Single Sign On（以下簡稱SSO），是指在多系統應用群中登錄一個系統，便可在其他所有系統中得到授權而無需再次登錄，包括單點登錄與單點注銷兩部分

1、登錄

　　相比於單系統登錄，sso需要一個獨立的認證中心，只有認證中心能接受用戶的用戶名密碼等安全信息，其他系統不提供登錄入口，只接受認證中心的間接授權。間接授權通過令牌實現，sso認證中心驗證用戶的用戶名密碼沒問題，創建授權令牌，在接下來的跳轉過程中，授權令牌作為參數發送給各個子系統，子系統拿到令牌，即得到了授權，可以借此創建局部會話，局部會話登錄方式與單系統的登錄方式相同。這個過程，也就是單點登錄的原理，用下圖說明

　　下面對上圖簡要描述

1. 用戶訪問系統1的受保護資源，系統1發現用戶未登錄，跳轉至sso認證中心，並將自己的地址作為參數
2. sso認證中心發現用戶未登錄，將用戶引導至登錄頁面
3. 用戶輸入用戶名密碼提交登錄申請
4. sso認證中心校驗用戶信息，創建用戶與sso認證中心之間的會話，稱為全局會話，同時創建授權令牌
5. sso認證中心帶着令牌跳轉會最初的請求地址（系統1）
6. 系統1拿到令牌，去sso認證中心校驗令牌是否有效
7. sso認證中心校驗令牌，返回有效，注冊系統1
8. 系統1使用該令牌創建與用戶的會話，稱為局部會話，返回受保護資源
9. 用戶訪問系統2的受保護資源
10. 系統2發現用戶未登錄，跳轉至sso認證中心，並將自己的地址作為參數
11. sso認證中心發現用戶已登錄，跳轉回系統2的地址，並附上令牌
12. 系統2拿到令牌，去sso認證中心校驗令牌是否有效
13. sso認證中心校驗令牌，返回有效，注冊系統2
14. 系統2使用該令牌創建與用戶的局部會話，返回受保護資源

　　用戶登錄成功之后，會與sso認證中心及各個子系統建立會話，用戶與sso認證中心建立的會話稱為全局會話，用戶與各個子系統建立的會話稱為局部會話，局部會話建立之后，用戶訪問子系統受保護資源將不再通過sso認證中心，全局會話與局部會話有如下約束關系

1. 局部會話存在，全局會話一定存在
2. 全局會話存在，局部會話不一定存在
3. 全局會話銷毀，局部會話必須銷毀

　　你可以通過博客園、百度、csdn、淘寶等網站的登錄過程加深對單點登錄的理解，注意觀察登錄過程中的跳轉url與參數

2、注銷

　　單點登錄自然也要單點注銷，在一個子系統中注銷，所有子系統的會話都將被銷毀，用下面的圖來說明

　　sso認證中心一直監聽全局會話的狀態，一旦全局會話銷毀，監聽器將通知所有注冊系統執行注銷操作

　　下面對上圖簡要說明

1. 用戶向系統1發起注銷請求
2. 系統1根據用戶與系統1建立的會話id拿到令牌，向sso認證中心發起注銷請求
3. sso認證中心校驗令牌有效，銷毀全局會話，同時取出所有用此令牌注冊的系統地址
4. sso認證中心向所有注冊系統發起注銷請求
5. 各注冊系統接收sso認證中心的注銷請求，銷毀局部會話
6. sso認證中心引導用戶至登錄頁面

四、部署圖

　　單點登錄涉及sso認證中心與眾子系統，子系統與sso認證中心需要通信以交換令牌、校驗令牌及發起注銷請求，因而子系統必須集成sso的客戶端，sso認證中心則是sso服務端，整個單點登錄過程實質是sso客戶端與服務端通信的過程，用下圖描述

　　sso認證中心與sso客戶端通信方式有多種，這里以簡單好用的httpClient為例，web service、rpc、restful api都可以

五、實現

　　只是簡要介紹下基於java的實現過程，不提供完整源碼，明白了原理，我相信你們可以自己實現。sso采用客戶端/服務端架構，我們先看sso-client與sso-server要實現的功能（下面：sso認證中心=sso-server）

　　sso-client

1. 攔截子系統未登錄用戶請求，跳轉至sso認證中心
2. 接收並存儲sso認證中心發送的令牌
3. 與sso-server通信，校驗令牌的有效性
4. 建立局部會話
5. 攔截用戶注銷請求，向sso認證中心發送注銷請求
6. 接收sso認證中心發出的注銷請求，銷毀局部會話

　　sso-server

1. 驗證用戶的登錄信息
2. 創建全局會話
3. 創建授權令牌
4. 與sso-client通信發送令牌
5. 校驗sso-client令牌有效性
6. 系統注冊
7. 接收sso-client注銷請求，注銷所有會話

　　接下來，我們按照原理來一步步實現sso吧！

1、sso-client攔截未登錄請求

　　java攔截請求的方式有servlet、filter、listener三種方式，我們采用filter。在sso-client中新建LoginFilter.java類並實現Filter接口，在doFilter()方法中加入對未登錄用戶的攔截

1 2 3 4 5 6 7 8 9 10 11 12

public  void  doFilter(ServletRequest request, ServletResponse response, FilterChain chain)  throws  IOException, ServletException {      HttpServletRequest req = (HttpServletRequest) request;      HttpServletResponse res = (HttpServletResponse) response;      HttpSession session = req.getSession();            if  (session.getAttribute( "isLogin" )) {          chain.doFilter(request, response);          return ;      }      //跳轉至sso認證中心      res.sendRedirect( "sso-server-url-with-system-url" ); }

2、sso-server攔截未登錄請求

　　攔截從sso-client跳轉至sso認證中心的未登錄請求，跳轉至登錄頁面，這個過程與sso-client完全一樣

3、sso-server驗證用戶登錄信息

　　用戶在登錄頁面輸入用戶名密碼，請求登錄，sso認證中心校驗用戶信息，校驗成功，將會話狀態標記為“已登錄”

1 2 3 4 5 6

@RequestMapping ( "/login" ) public  String login(String username, String password, HttpServletRequest req) {      this .checkLoginInfo(username, password);      req.getSession().setAttribute( "isLogin" ,  true );      return  "success" ; }

4、sso-server創建授權令牌

　　授權令牌是一串隨機字符，以什么樣的方式生成都沒有關系，只要不重復、不易偽造即可，下面是一個例子

1	String token = UUID.randomUUID().toString();

5、sso-client取得令牌並校驗

　　sso認證中心登錄后，跳轉回子系統並附上令牌，子系統（sso-client）取得令牌，然后去sso認證中心校驗，在LoginFilter.java的doFilter()中添加幾行

1 2 3 4 5 6 7 8 9 10 11

// 請求附帶token參數 String token = req.getParameter( "token" ); if  (token !=  null ) {      // 去sso認證中心校驗token      boolean  verifyResult =  this .verify( "sso-server-verify-url" , token);      if  (!verifyResult) {          res.sendRedirect( "sso-server-url" );          return ;      }      chain.doFilter(request, response); }

　　verify()方法使用httpClient實現，這里僅簡略介紹，httpClient詳細使用方法請參考官方文檔

1 2	HttpPost httpPost =  new  HttpPost( "sso-server-verify-url-with-token" ); HttpResponse httpResponse = httpClient.execute(httpPost);

6、sso-server接收並處理校驗令牌請求

　　用戶在sso認證中心登錄成功后，sso-server創建授權令牌並存儲該令牌，所以，sso-server對令牌的校驗就是去查找這個令牌是否存在以及是否過期，令牌校驗成功后sso-server將發送校驗請求的系統注冊到sso認證中心（就是存儲起來的意思）

　　令牌與注冊系統地址通常存儲在key-value數據庫（如redis）中，redis可以為key設置有效時間也就是令牌的有效期。redis運行在內存中，速度非常快，正好sso-server不需要持久化任何數據。

　　令牌與注冊系統地址可以用下圖描述的結構存儲在redis中，可能你會問，為什么要存儲這些系統的地址？如果不存儲，注銷的時候就麻煩了，用戶向sso認證中心提交注銷請求，sso認證中心注銷全局會話，但不知道哪些系統用此全局會話建立了自己的局部會話，也不知道要向哪些子系統發送注銷請求注銷局部會話

7、sso-client校驗令牌成功創建局部會話

　　令牌校驗成功后，sso-client將當前局部會話標記為“已登錄”，修改LoginFilter.java，添加幾行

1 2 3

if  (verifyResult) {      session.setAttribute( "isLogin" ,  true ); }

　　sso-client還需將當前會話id與令牌綁定，表示這個會話的登錄狀態與令牌相關，此關系可以用java的hashmap保存，保存的數據用來處理sso認證中心發來的注銷請求

8、注銷過程

　　用戶向子系統發送帶有“logout”參數的請求（注銷請求），sso-client攔截器攔截該請求，向sso認證中心發起注銷請求

1 2 3 4

String logout = req.getParameter( "logout" ); if  (logout !=  null ) {      this .ssoServer.logout(token); }

　　sso認證中心也用同樣的方式識別出sso-client的請求是注銷請求（帶有“logout”參數），sso認證中心注銷全局會話

1 2 3 4 5 6 7 8

@RequestMapping ( "/logout" ) public  String logout(HttpServletRequest req) {      HttpSession session = req.getSession();      if  (session !=  null ) {          session.invalidate(); //觸發LogoutListener      }      return  "redirect:/" ; }

　　sso認證中心有一個全局會話的監聽器，一旦全局會話注銷，將通知所有注冊系統注銷

1 2 3 4 5 6 7 8

public  class  LogoutListener  implements  HttpSessionListener {      @Override      public  void  sessionCreated(HttpSessionEvent event) {}      @Override      public  void  sessionDestroyed(HttpSessionEvent event) {          //通過httpClient向所有注冊系統發送注銷請求      } }