1. 基礎概念

SSO單點登錄（Single sign-on）

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

CAS 中央認證服務（Central Authentication Service）

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

OAuth2.0 開放授權（Open Authorization）

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

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

SSO僅僅是一種設計架構，而CAS和OAuth是SSO的一種實現(xiàn)方式，他們之間是抽象與具象的關系。

2. 單點登錄

讓我們用兩張圖來看一下闡述一下單點登錄的設計流程：

打個比方，SSO 和我們去迪士尼玩時購買的通票很像，我們只要買一次通票，就可以玩所有游樂場內的設施，而不需要在過山車或者摩天輪那里重新買一次票。在這里，買票就相當于登錄認證，游樂場就相當于使用一套 SSO 的公司，各種游樂設施就相當于公司的各個產(chǎn)品。

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

提升用戶體驗

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

避免重復開發(fā)

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

提升安全系數(shù)

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

3. CAS 流程

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

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

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

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

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

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

4. OAuth 流程

OAuth2.0的四種授權方式

1. 授權碼(authorization code)

這是最常用的一種方式，指的是第三方應用先申請一個授權碼，然后再用該碼獲取令牌，項目中常用的就是這種
—這種模式算是正宗的oauth2的授權模式
—設計了auth code，通過這個code再獲取token
—支持refresh token

2. 隱藏式(implicit)

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

3. 密碼式(resource owner password credentials)

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

4. 憑證式(client credentials)

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

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

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

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

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

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

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

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

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

最新評論