什麼是單點登入？
先來看看最初的應用架構：
經典的單體架構，服務中包含了三個模組，部署在乙個伺服器中。使用者與服務端建立會話的方式是利用cookeis和session（見第二章節cookies和session）。但是隨著系統內的業務越來越多，單個伺服器已經不能滿足效能要求，並且業務之間的互動越來愈多，業務耦合性很高，維護起來很麻煩，於是就把按每個業務單獨分開來，形成乙個子系統，使用者需要每個系統的業務，就去對應的子系統訪問，如下圖：
使用者需要對應的業務需求就去對應的子系統請求。當然這裡的系統只是簡單的拆分，各自系統之間的互動，系統的管理和治理這裡都不講，涉及到微服務的東西，以後再學習。這裡講單點登入足夠了。使用者在系統1登入之後，再去系統2、3……n都不需要登入了。舉個例子，拿**和天貓來說，如果你在**的頁面登入了，然後開啟天貓的頁面，你會發現你再天貓已經登入，並不用再天貓再登入一次，包括支付寶也是一樣。
所謂的單點登入，功能可以簡單的看做，有相關聯子系統（比如天貓、**、支付寶都是不同的系統），在其中乙個登入之後，在進入其他子系統的時候，並不需要重新登入。這裡的關鍵點在於，我在系統1登入之後，於系統1建立了聯絡，那麼我怎麼通知系統2,3……n,讓他們知道我在系統1登陸了，到你們這裡也就不用登陸了。
類似於上圖這個意思，我們的重點在於解決第⑥⑦步的問題，該怎麼設計實現。
所以這一次，我們就從頭一步一步就來看看，單點登入是怎麼設計的。
從系統登入說起：
系統的登入想必大家都不陌生，使用者在登陸介面登入，後台接受使用者名稱和密碼後，驗證正確性，使用者方可進入系統各頁面。使用者和服務端建立會話，此後的一段時間內，使用者都不需要重新輸入使用者名稱密碼，訪問服務。
注意這裡的「會話」，這表示和服務端建立了聯絡，每次請求服務端都知道這個請求是你發過來的。但是我們都知道，http的請求是無狀態的，每次建立連線都要三次握手，服務端並不能判斷哪個http是你傳送的，那麼這裡的會話是如何建立起來的，讓服務端可以識別你呢? 這就要提到cookies和session了。
cookeis用於服務端返回給客戶端的使用者相關資訊，在使用者登入成功後，服務端會返回給瀏覽器端一些使用者的資訊，然後存放與瀏覽器端，每次瀏覽器發起請求時都會攜帶上cookies資訊
session時使用者首次登入後，服務端用於記錄每個使用者資訊的東西，存放於服務端，每次請求過來之後，根據cookies中的資訊，查詢對應的session,進而找到session中的session資訊。
而cookies和session互動的方式就是jessionid,具體互動方式如下：
使用者首次訪問頁面（登入成功）伺服器（如tomcat）會為這個客戶端隨機生成一串字串，即jessionid,並開闢乙個空間存放使用者的資訊，如登入時間，使用者角色等，所以在服務端的session存放的方式類似於map,key值就是jessionid,value值相當於session：
如上圖所示，每個user相當於乙個瀏覽器，服務端的session就類似於存放了這樣的結構。然後客戶端會把jsessionid和瀏覽器需要知道使用者資訊放進cookies中，返回給瀏覽器。
此後瀏覽器每次訪問服務端，都會攜帶上cookies，自然也就攜帶了sessionid,服務端在收到請求之後，會判斷有沒有jseesionid：
如果沒有，那說明使用者是第一次訪問（也有可能是存放在客戶端的session過期了，session是有效期的，過期就需要重新登入進行獲取），那麼需要跳轉到登入頁面進行登入。
如果存在，那服務端會拿到jessionid,和上面的這張表進行匹配，匹配到之後說明使用者已經登入，然後進而獲取使用者的資訊，比如user1 information,獲得使用者許可權之類的資訊，然後進而對請求做出響應。整體流程圖如下：
其實你會發現，在進行開發的時候，我們並沒有對jseesionid進行進行校驗和檢查之類的**編寫，這是因為這一步（包括建立session,建立jsessionid,jsessionid的校驗）是tomcat（如果你的伺服器用的是tomcat）自動為我們做了。而我們要做的就是在使用者登入後在cookeis中設定瀏覽器所需要的的使用者資訊，和使用者請求，根據jessionid獲取session,獲取或設定session中的使用者資訊進行響應,這裡cookies和session中存放的資料，由業務而定。
需要注意的是，這裡的cookies和session是有效期的。
對於session來說，有效期可以在服務端程式中設定，也可以在tomcat的配置檔案中設定。超過設定的失效時間後，在接受客戶端的請求時，就可以讓其重新登入。達到登入時間的控制。如果使用者在有效期請求，每次請求都會重新整理session的有效期，從新計算，從而維持登入狀態。只有用常識不發起請求，到了失效時間才會把對應session刪除，使用者再次請求時需要重新獲取（重新登入）
為了更方便的了解，下面來實際看一看乙個簡單的測試：這裡搭建了乙個空工程，就訪問index.jsp頁面，當我們第一次訪問**的時候，在瀏覽器開發這工具中（f12進入），找到network中的heaaders：
正如我們上面說的那樣，由於是第一次請求，在請求頭部request headers中並沒有攜帶cookies進行請求，反而是客戶端在監測第一次登陸沒有發現在cookies中jessionid的時候，生成了乙個cookies，返回給瀏覽器，在responseheaders中可以看到set-cookies裡面就有生成的乙個jessionid（紅線所示）。然後瀏覽器會存放在本地，下次請求的時候機會攜帶上cookeis。接下來我們重新整理一下頁面，再發一次請求：
正如我們所想的那樣，在請求頭request headers中攜帶了cookies,並且裡面有jessionid。對比一下就會發現這個jsession就是第一次請求時服務端返回的jessionid。說明瀏覽器的確儲存了服務端返回的cookies，並在下一次請求的時候攜帶上了，以供服務端進行校驗。
單點登入設計
sso是single sign on的縮寫，翻譯成中文是單點登入的意思，所謂的單點登入是指在有多個應用系統的情況下，成功登入任一應用系統後再登入其他的系統是不用再輸入使用者名稱密碼登入而直接可以登入到系統。一般使用cookie技術實現。瀏覽器需要支援cookie 所有的應用系統在同乙個頂級域內，比如...
單點登入實現
什麼是單點登入 單點登入就是 你有好幾個應用，然後只需要在其中乙個應用裡面登入以後，就不需要在其他系統裡面登入了。打個比方 你在北京辦了一張銀行卡，然後到了上海這張銀行卡依舊可以使用。單點登入應用場景單點登入的實現 呵呵，重要講到我們的主題上來了。單點登入的實現，其實實現的就是維持乙個回話。我下面給...
單點登入實現
簡介原理 使用者已經通過認證中心的認證後 使用者訪問系統2的保護資源，系統2發現使用者未登入，跳轉至sso認證中心，sso認證中心發現使用者已經登入，就會帶著令牌跳轉回系統2，系統2拿到令牌後去sso認證中心校驗令牌是否有效，sso認證中心返回有效，註冊系統2，系統2使用該令牌建立與使用者的區域性會...