背景

在企業(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)塔逃。

image

如圖所示，圖中有4個系統(tǒng)料仗，分別是Application1患雏、Application2、Application3罢维、和SSO淹仑。Application1、Application2肺孵、Application3沒有登錄模塊匀借，而SSO只有登錄模塊，沒有其他的業(yè)務模塊平窘，當Application1吓肋、Application2、Application3需要登錄時瑰艘，將跳到SSO系統(tǒng)是鬼，SSO系統(tǒng)完成登錄，其他的應用系統(tǒng)也就隨之登錄了紫新。這完全符合我們對單點登錄（SSO）的定義均蜜。

技術(shù)實現(xiàn)

在說單點登錄（SSO）的技術(shù)實現(xiàn)之前，我們先說一說普通的登錄認證機制芒率。

image

如上圖所示囤耳，我們在瀏覽器（Browser）中訪問一個應用，這個應用需要登錄偶芍，我們填寫完用戶名和密碼后充择，完成登錄認證。這時匪蟀，我們在這個用戶的session中標記登錄狀態(tài)為yes（已登錄）椎麦，同時在瀏覽器（Browser）中寫入Cookie，這個Cookie是這個用戶的唯一標識材彪。下次我們再訪問這個應用的時候观挎，請求中會帶上這個Cookie撒桨，服務端會根據(jù)這個Cookie找到對應的session，通過session來判斷這個用戶是否登錄键兜。如果不做特殊配置凤类，這個Cookie的名字叫做jsessionid，值在服務端（server）是唯一的普气。

同域下的單點登錄

一個企業(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)潭苞，是不共享的忽冻。

image

那么我們?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_flow_diagram

上圖是CAS官網(wǎng)上的標準流程码倦，具體流程如下：

1. 用戶訪問app系統(tǒng)，app系統(tǒng)是需要登錄的锭碳，但用戶現(xiàn)在沒有登錄袁稽。
2. 跳轉(zhuǎn)到CAS server，即SSO登錄系統(tǒng)擒抛，以后圖中的CAS Server我們統(tǒng)一叫做SSO系統(tǒng)推汽。 SSO系統(tǒng)也沒有登錄，彈出用戶登錄頁歧沪。
3. 用戶填寫用戶名歹撒、密碼，SSO系統(tǒng)進行認證后诊胞，將登錄狀態(tài)寫入SSO的session暖夭，瀏覽器（Browser）中寫入SSO域下的Cookie。
4. SSO系統(tǒng)登錄完成后會生成一個ST（Service Ticket）撵孤，然后跳轉(zhuǎn)到app系統(tǒng)迈着，同時將ST作為參數(shù)傳遞給app系統(tǒng)。
5. app系統(tǒng)拿到ST后邪码，從后臺向SSO發(fā)送請求裕菠，驗證ST是否有效。
6. 驗證通過后闭专，app系統(tǒng)將登錄狀態(tài)寫入session并設置app域下的Cookie奴潘。

至此旧烧，跨域單點登錄就完成了。以后我們再訪問app系統(tǒng)時画髓，app就是登錄的掘剪。接下來，我們再看看訪問app2系統(tǒng)時的流程奈虾。

1. 用戶訪問app2系統(tǒng)杖小，app2系統(tǒng)沒有登錄，跳轉(zhuǎn)到SSO愚墓。
2. 由于SSO已經(jīng)登錄了予权，不需要重新登錄認證。
3. SSO生成ST浪册，瀏覽器跳轉(zhuǎn)到app2系統(tǒng)扫腺，并將ST作為參數(shù)傳遞給app2。
4. app2拿到ST笆环，后臺訪問SSO厚者，驗證ST是否有效躁劣。
5. 驗證成功后，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是否有效，是有效的我才能讓這個用戶訪問喜鼓。