1. 基礎(chǔ)概念

SSO單點(diǎn)登錄（Single sign-on）

所謂單點(diǎn)登錄就是在多個應(yīng)用系統(tǒng)中，用戶只需登錄一次就可以訪問所有相互信任的系統(tǒng)。

CAS 中央認(rèn)證服務(wù)（Central Authentication Service）

CAS是由美國耶魯大學(xué)發(fā)起的一個企業(yè)級開源項(xiàng)目，旨在為WEB應(yīng)用系統(tǒng)提供一種可靠的單點(diǎn)登錄解決方案（WEB SSO）。

OAuth2.0 開放授權(quán)（Open Authorization）

OAuth2.0是一個為用戶資源授權(quán)定義的安全標(biāo)準(zhǔn)，主要用于第三方應(yīng)用授權(quán)登錄，由于OAuth1.0標(biāo)準(zhǔn)存在安全漏洞現(xiàn)在已升級到2.0版本。

SSO單點(diǎn)登錄與CAS 和OAuth之間有什么區(qū)別

SSO僅僅是一種設(shè)計(jì)架構(gòu)，而CAS和OAuth是SSO的一種實(shí)現(xiàn)方式，他們之間是抽象與具象的關(guān)系。

2. 單點(diǎn)登錄

讓我們用兩張圖來看一下闡述一下單點(diǎn)登錄的設(shè)計(jì)流程：

打個比方，SSO 和我們?nèi)サ鲜磕嵬鏁r購買的通票很像，我們只要買一次通票，就可以玩所有游樂場內(nèi)的設(shè)施，而不需要在過山車或者摩天輪那里重新買一次票。在這里，買票就相當(dāng)于登錄認(rèn)證，游樂場就相當(dāng)于使用一套 SSO 的公司，各種游樂設(shè)施就相當(dāng)于公司的各個產(chǎn)品。

使用 SSO 的優(yōu)點(diǎn)很明顯：

提升用戶體驗(yàn)

就以我廠為例。我廠有兩個產(chǎn)品，丁香人才網(wǎng)和丁香園論壇，假如你是我廠用戶，肯定無法忍受登錄丁香園論壇的時候輸入一次用戶名密碼，登錄人才網(wǎng)又要輸入一次用戶名密碼吧？

避免重復(fù)開發(fā)

假如你是我廠后端，每天任務(wù)都飽和的不行，肯定無法忍受到人才網(wǎng)開發(fā)一套登錄邏輯，到論壇又開發(fā)一套登錄邏輯吧？

提升安全系數(shù)

假如你是我廠運(yùn)維，發(fā)現(xiàn)了一個安全隱患需要緊急修復(fù)。你肯定無法忍受給茫茫多的產(chǎn)品后端都發(fā)一封郵件，責(zé)令修復(fù)吧？萬一漏了一個呢？。

3. CAS 流程

下面讓我們用一張圖來說明一下用戶是如何在兩個不同系統(tǒng)中如何實(shí)現(xiàn)CAS單點(diǎn)登錄的。

• CAS系統(tǒng) （cas.qiandu.com）
• 門戶系統(tǒng) （www.qiandu.com）
• 郵箱系統(tǒng)（mail.qiandu.com）

1. 用戶訪問門戶系統(tǒng)，門戶系統(tǒng)是需要登錄的，但用戶現(xiàn)在沒有登錄。
2. 跳轉(zhuǎn)到CAS認(rèn)證服務(wù)，即CAS的登錄系統(tǒng)。 CAS系統(tǒng)也沒有登錄，彈出用戶登錄頁。
3. 用戶填寫用戶名、密碼，CAS系統(tǒng)進(jìn)行認(rèn)證后，將登錄狀態(tài)寫入CAS的session，瀏覽器中寫入cas.qiandu.com域下的Cookie。
4. CAS系統(tǒng)登錄完成后會生成一個ST（Service Ticket），然后跳轉(zhuǎn)到門戶系統(tǒng)，同時將ST作為參數(shù)傳遞給門戶系統(tǒng)。
5. 門戶系統(tǒng)拿到ST后，從后臺向CAS系統(tǒng)發(fā)送請求，驗(yàn)證ST是否有效。
6. 驗(yàn)證通過后，門戶系統(tǒng)將登錄狀態(tài)寫入session并設(shè)置www.qiandu.com域下的Cookie。

至此，跨域單點(diǎn)登錄就完成了。以后我們再訪問門戶系統(tǒng)時，門戶就是登錄的。接下來，我們再看看訪問郵箱系統(tǒng)時的流程。

• 1. 用戶訪問郵箱系統(tǒng)，郵箱系統(tǒng)沒有登錄，跳轉(zhuǎn)到CAS系統(tǒng)。
• 2. 由于CAS系統(tǒng)已經(jīng)登錄了，不需要重新登錄認(rèn)證。
• 3. CAS系統(tǒng)生成ST，瀏覽器跳轉(zhuǎn)到郵箱系統(tǒng)，并將ST作為參數(shù)傳遞給郵箱系統(tǒng)。
• 4. 郵箱系統(tǒng)拿到ST，后臺訪問CAS系統(tǒng)，驗(yàn)證ST是否有效。
• 5. 驗(yàn)證成功后，郵箱系統(tǒng)將登錄狀態(tài)寫入session，并在mail.qiandu.com域下寫入Cookie。

這樣，app2系統(tǒng)不需要走登錄流程，就已經(jīng)是登錄了。SSO，app和app2在不同的域，它們之間的session不共享也是沒問題的。

4. OAuth 流程

OAuth2.0的四種授權(quán)方式

1. 授權(quán)碼(authorization code)

這是最常用的一種方式，指的是第三方應(yīng)用先申請一個授權(quán)碼，然后再用該碼獲取令牌，項(xiàng)目中常用的就是這種
—這種模式算是正宗的oauth2的授權(quán)模式
—設(shè)計(jì)了auth code，通過這個code再獲取token
—支持refresh token

2. 隱藏式(implicit)

允許直接向前端頒發(fā)令牌。這種方式?jīng)]有授權(quán)碼這個中間步驟，所以稱為（授權(quán)碼）“隱藏式”，一般應(yīng)用于純前端項(xiàng)目
—這種模式比授權(quán)碼模式少了code環(huán)節(jié)，回調(diào)url直接攜帶token
—這種模式的使用場景是基于瀏覽器的應(yīng)用
—這種模式基于安全性考慮，建議把token時效設(shè)置短一些
—不支持refresh token

3. 密碼式(resource owner password credentials)

直接通過用戶名和密碼的方式申請令牌，這方式是最不安全的方式
—這種模式是最不推薦的，因?yàn)閏lient可能存了用戶密碼
—這種模式主要用來做遺留項(xiàng)目升級為oauth2的適配方案
—當(dāng)然如果client是自家的應(yīng)用，也是可以
—支持refresh token

4. 憑證式(client credentials)

這種方式的令牌是針對第三方應(yīng)用，而不是針對用戶的，既某個第三方應(yīng)用的所有用戶共用一個令牌，一般用于后臺api服務(wù)消費(fèi)者設(shè)計(jì)
—這種模式直接根據(jù)client的id和密鑰即可獲取token，無需用戶參與
—這種模式比較合適消費(fèi)api的后端服務(wù)，比如拉取一些用戶信息等
—不支持refresh token

5. CAS和OAuth的區(qū)別

CAS的單點(diǎn)登錄時保障客戶端的用戶資源的安全，客戶端要獲取的最終信息是，這個用戶到底有沒有權(quán)限訪問我（CAS客戶端）的資源。

CAS的單點(diǎn)登錄，資源都在客戶端這邊，不在CAS的服務(wù)器那一方。用戶在給CAS服務(wù)端提供了用戶名密碼后，作為CAS客戶端并不知道這件事。隨便給客戶端個ST，那么客戶端是不能確定這個ST是用戶偽造還是真的有效，所以要拿著這個ST去服務(wù)端再問一下，這個用戶給我的是有效的ST還是無效的ST，是有效的我才能讓這個用戶訪問。

OAuth2.0則是保障服務(wù)端的用戶資源的安全，獲取的最終信息是，我（OAuth2.0服務(wù)提供方）的用戶的資源到底能不能讓你（OAuth2.0的客戶端）訪問。

所以在最安全的模式下，用戶授權(quán)之后，服務(wù)端并不能直接返回token，通過重定向送給客戶端，因?yàn)檫@個token有可能被黑客截獲，如果黑客截獲了這個token，那用戶的資源也就暴露在這個黑客之下了。

于是聰明的服務(wù)端發(fā)送了一個認(rèn)證code給客戶端（通過重定向），客戶端在后臺，通過https的方式，用這個code，以及另一串客戶端和服務(wù)端預(yù)先商量好的密碼，才能獲取到token和刷新token，這個過程是非常安全的。

如果黑客截獲了code，他沒有那串預(yù)先商量好的密碼，他也是無法獲取token的。這樣oauth2就能保證請求資源這件事，是用戶同意的，客戶端也是被認(rèn)可的，可以放心的把資源發(fā)給這個客戶端了

到此這篇關(guān)于入門到精通Java SSO單點(diǎn)登錄原理詳解的文章就介紹到這了,更多相關(guān)SSO單點(diǎn)登錄內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論