背景
在企業(yè)發(fā)展初期凿歼，企業(yè)使用的系統(tǒng)很少褪迟，通常一個或者兩個，每個系統(tǒng)都有自己的登錄模塊答憔，運營人員每天用自己的賬號登錄味赃，很方便。
但隨著企業(yè)的發(fā)展攀唯，用到的系統(tǒng)隨之增多洁桌，運營人員在操作不同的系統(tǒng)時，需要多次登錄侯嘀，而且每個系統(tǒng)的賬號都不一樣另凌，這對于運營人員
來說，很不方便戒幔。于是吠谢，就想到是不是可以在一個系統(tǒng)登錄，其他系統(tǒng)就不用登錄了呢诗茎？這就是單點登錄要解決的問題工坊。
單點登錄英文全稱Single Sign On，簡稱就是SSO敢订。它的解釋是：在多個應用系統(tǒng)中王污，只需要登錄一次，就可以訪問其他相互信任的應用系統(tǒng)楚午。
技術(shù)實現(xiàn)
在說單點登錄（SSO）的技術(shù)實現(xiàn)之前昭齐，我們先說一說普通的登錄認證機制。
同域下的單點登錄
一個企業(yè)一般情況下只有一個域名矾柜，通過二級域名區(qū)分不同的系統(tǒng)阱驾。比如我們有個域名叫做：a.com就谜，同時有兩個業(yè)務系統(tǒng)分別為：app1.a.com和app2.a.com。我們要做單點登錄（SSO）里覆，需要一個登錄系統(tǒng)丧荐，叫做：sso.a.com。
我們只要在sso.a.com登錄喧枷，app1.a.com和app2.a.com就也登錄了虹统。通過上面的登陸認證機制，我們可以知道割去，在sso.a.com中登錄了窟却，其實是在sso.a.com的服務端的session中記錄了登錄狀態(tài)，同時在瀏覽器端（Browser）的sso.a.com下寫入了Cookie呻逆。那么我們怎么才能讓app1.a.com和app2.a.com登錄呢？這里有兩個問題：
Cookie是不能跨域的菩帝，我們Cookie的domain屬性是sso.a.com咖城，在給app1.a.com和app2.a.com發(fā)送請求是帶不上的。
sso呼奢、app1和app2是不同的應用宜雀，它們的session存在自己的應用內(nèi)，是不共享的握础。
那么我們?nèi)绾谓鉀Q這兩個問題呢辐董？針對第一個問題，sso登錄以后禀综，可以將Cookie的域設置為頂域简烘，即.a.com，這樣所有子域的系統(tǒng)都可以訪問到頂域的Cookie定枷。我們在設置Cookie時孤澎，只能設置頂域和自己的域，不能設置其他的域欠窒。比如：我們不能在自己的系統(tǒng)中給baidu.com的域設置Cookie覆旭。
Cookie的問題解決了，我們再來看看session的問題岖妄。我們在sso系統(tǒng)登錄了型将，這時再訪問app1，Cookie也帶到了app1的服務端（Server）荐虐，app1的服務端怎么找到這個Cookie對應的Session呢七兜？這里就要把3個系統(tǒng)的Session共享，如圖所示缚俏。共享Session的解決方案有很多惊搏，例如：Spring-Session贮乳。這樣第2個問題也解決了。
同域下的單點登錄就實現(xiàn)了恬惯，但這還不是真正的單點登錄向拆。
不同域下的單點登錄
同域下的單點登錄是巧用了Cookie頂域的特性。如果是不同域呢酪耳？不同域之間Cookie是不共享的浓恳，怎么辦？
這里我們就要說一說CAS流程了碗暗，這個流程是單點登錄的標準流程颈将。
上圖是CAS官網(wǎng)上的標準流程，具體流程如下：
用戶訪問app系統(tǒng)言疗，app系統(tǒng)是需要登錄的晴圾，但用戶現(xiàn)在沒有登錄。
跳轉(zhuǎn)到CAS server噪奄，即SSO登錄系統(tǒng)死姚，以后圖中的CAS Server我們統(tǒng)一叫做SSO系統(tǒng)。 SSO系統(tǒng)也沒有登錄勤篮，彈出用戶登錄頁都毒。
用戶填寫用戶名、密碼碰缔，SSO系統(tǒng)進行認證后账劲，將登錄狀態(tài)寫入SSO的session，瀏覽器（Browser）中寫入SSO域下的Cookie金抡。
SSO系統(tǒng)登錄完成后會生成一個ST（Service Ticket）瀑焦，然后跳轉(zhuǎn)到app系統(tǒng)，同時將ST作為參數(shù)傳遞給app系統(tǒng)竟终。
app系統(tǒng)拿到ST后蝠猬，從后臺向SSO發(fā)送請求，驗證ST是否有效统捶。
驗證通過后榆芦，app系統(tǒng)將登錄狀態(tài)寫入session并設置app域下的Cookie。
至此喘鸟，跨域單點登錄就完成了匆绣。以后我們再訪問app系統(tǒng)時，app就是登錄的什黑。接下來崎淳，我們再看看訪問app2系統(tǒng)時的流程。
用戶訪問app2系統(tǒng)愕把，app2系統(tǒng)沒有登錄拣凹，跳轉(zhuǎn)到SSO森爽。
由于SSO已經(jīng)登錄了，不需要重新登錄認證嚣镜。
SSO生成ST爬迟，瀏覽器跳轉(zhuǎn)到app2系統(tǒng)，并將ST作為參數(shù)傳遞給app2菊匿。
app2拿到ST付呕，后臺訪問SSO，驗證ST是否有效跌捆。
驗證成功后徽职，app2將登錄狀態(tài)寫入session，并在app2域下寫入Cookie佩厚。
這樣姆钉，app2系統(tǒng)不需要走登錄流程，就已經(jīng)是登錄了抄瓦。SSO育韩，app和app2在不同的域，它們之間的session不共享也是沒問題的闺鲸。
有的同學問我，SSO系統(tǒng)登錄后埃叭，跳回原業(yè)務系統(tǒng)時摸恍，帶了個參數(shù)ST，業(yè)務系統(tǒng)還要拿ST再次訪問SSO進行驗證赤屋，覺得這個步驟有點多余立镶。他想SSO登錄認證通過后，通過回調(diào)地址將用戶信息返回給原業(yè)務系統(tǒng)类早，原業(yè)務系統(tǒng)直接設置登錄狀態(tài)媚媒，這樣流程簡單，也完成了登錄涩僻，不是很好嗎缭召？
其實這樣問題時很嚴重的，如果我在SSO沒有登錄逆日，而是直接在瀏覽器中敲入回調(diào)的地址嵌巷，并帶上偽造的用戶信息，是不是業(yè)務系統(tǒng)也認為登錄了呢室抽？這是很可怕的搪哪。
總結(jié)
單點登錄（SSO）的所有流程都介紹完了，原理大家都清楚了坪圾∠郏總結(jié)一下單點登錄要做的事情：
單點登錄（SSO系統(tǒng)）是保障各業(yè)務系統(tǒng)的用戶資源的安全 惑朦。
各個業(yè)務系統(tǒng)獲得的信息是，這個用戶能不能訪問我的資源漓概。
單點登錄漾月，資源都在各個業(yè)務系統(tǒng)這邊，不在SSO那一方垛耳。 用戶在給SSO服務器提供了用戶名密碼后栅屏，作為業(yè)務系統(tǒng)并不知道這件事。 SSO隨便給業(yè)務系統(tǒng)一個ST堂鲜，那么業(yè)務系統(tǒng)是不能確定這個ST是用戶偽造的栈雳，還是真的有效，所以要拿著這個ST去SSO服務器再問一下缔莲，這個用戶給我的ST是否有效哥纫，是有效的我才能讓這個用戶訪問。
