入門到精通Java?SSO單點(diǎn)登錄原理詳解
1. 基礎(chǔ)概念
SSO單點(diǎn)登錄(Single sign-on)
所謂單點(diǎn)登錄就是在多個(gè)應(yīng)用系統(tǒng)中,用戶只需登錄一次就可以訪問所有相互信任的系統(tǒng)。
CAS 中央認(rèn)證服務(wù)(Central Authentication Service)
CAS是由美國(guó)耶魯大學(xué)發(fā)起的一個(gè)企業(yè)級(jí)開源項(xiàng)目,旨在為WEB應(yīng)用系統(tǒng)提供一種可靠的單點(diǎn)登錄解決方案(WEB SSO)。
OAuth2.0 開放授權(quán)(Open Authorization)
OAuth2.0是一個(gè)為用戶資源授權(quán)定義的安全標(biāo)準(zhǔn),主要用于第三方應(yīng)用授權(quán)登錄,由于OAuth1.0標(biāo)準(zhǔn)存在安全漏洞現(xiàn)在已升級(jí)到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ì)流程:

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

使用 SSO 的優(yōu)點(diǎn)很明顯:
提升用戶體驗(yàn)
就以我廠為例。我廠有兩個(gè)產(chǎn)品,丁香人才網(wǎng)和丁香園論壇,假如你是我廠用戶,肯定無法忍受登錄丁香園論壇的時(shí)候輸入一次用戶名密碼,登錄人才網(wǎng)又要輸入一次用戶名密碼吧?
避免重復(fù)開發(fā)
假如你是我廠后端,每天任務(wù)都飽和的不行,肯定無法忍受到人才網(wǎng)開發(fā)一套登錄邏輯,到論壇又開發(fā)一套登錄邏輯吧?
提升安全系數(shù)
假如你是我廠運(yùn)維,發(fā)現(xiàn)了一個(gè)安全隱患需要緊急修復(fù)。你肯定無法忍受給茫茫多的產(chǎn)品后端都發(fā)一封郵件,責(zé)令修復(fù)吧?萬一漏了一個(gè)呢?。
3. CAS 流程
下面讓我們用一張圖來說明一下用戶是如何在兩個(gè)不同系統(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)也沒有登錄,彈出用戶登錄頁(yè)。
3. 用戶填寫用戶名、密碼,CAS系統(tǒng)進(jìn)行認(rèn)證后,將登錄狀態(tài)寫入CAS的session,瀏覽器中寫入cas.qiandu.com域下的Cookie。
4. CAS系統(tǒng)登錄完成后會(huì)生成一個(gè)ST(Service Ticket),然后跳轉(zhuǎn)到門戶系統(tǒng),同時(shí)將ST作為參數(shù)傳遞給門戶系統(tǒng)。
5. 門戶系統(tǒng)拿到ST后,從后臺(tái)向CAS系統(tǒng)發(fā)送請(qǐng)求,驗(yàn)證ST是否有效。
6. 驗(yàn)證通過后,門戶系統(tǒng)將登錄狀態(tài)寫入session并設(shè)置www.qiandu.com域下的Cookie。
至此,跨域單點(diǎn)登錄就完成了。以后我們?cè)僭L問門戶系統(tǒng)時(shí),門戶就是登錄的。接下來,我們?cè)倏纯丛L問郵箱系統(tǒng)時(shí)的流程。
- 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,后臺(tái)訪問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)用先申請(qǐng)一個(gè)授權(quán)碼,然后再用該碼獲取令牌,項(xiàng)目中常用的就是這種
—這種模式算是正宗的oauth2的授權(quán)模式
—設(shè)計(jì)了auth code,通過這個(gè)code再獲取token
—支持refresh token
2. 隱藏式(implicit)
允許直接向前端頒發(fā)令牌。這種方式?jīng)]有授權(quán)碼這個(gè)中間步驟,所以稱為(授權(quán)碼)“隱藏式”,一般應(yīng)用于純前端項(xiàng)目
—這種模式比授權(quán)碼模式少了code環(huán)節(jié),回調(diào)url直接攜帶token
—這種模式的使用場(chǎng)景是基于瀏覽器的應(yīng)用
—這種模式基于安全性考慮,建議把token時(shí)效設(shè)置短一些
—不支持refresh token
3. 密碼式(resource owner password credentials)
直接通過用戶名和密碼的方式申請(qǐng)令牌,這方式是最不安全的方式
—這種模式是最不推薦的,因?yàn)閏lient可能存了用戶密碼
—這種模式主要用來做遺留項(xiàng)目升級(jí)為oauth2的適配方案
—當(dāng)然如果client是自家的應(yīng)用,也是可以
—支持refresh token
4. 憑證式(client credentials)
這種方式的令牌是針對(duì)第三方應(yīng)用,而不是針對(duì)用戶的,既某個(gè)第三方應(yīng)用的所有用戶共用一個(gè)令牌,一般用于后臺(tái)api服務(wù)消費(fèi)者設(shè)計(jì)
—這種模式直接根據(jù)client的id和密鑰即可獲取token,無需用戶參與
—這種模式比較合適消費(fèi)api的后端服務(wù),比如拉取一些用戶信息等
—不支持refresh token
5. CAS和OAuth的區(qū)別
CAS的單點(diǎn)登錄時(shí)保障客戶端的用戶資源的安全,客戶端要獲取的最終信息是,這個(gè)用戶到底有沒有權(quán)限訪問我(CAS客戶端)的資源。
CAS的單點(diǎn)登錄,資源都在客戶端這邊,不在CAS的服務(wù)器那一方。用戶在給CAS服務(wù)端提供了用戶名密碼后,作為CAS客戶端并不知道這件事。隨便給客戶端個(gè)ST,那么客戶端是不能確定這個(gè)ST是用戶偽造還是真的有效,所以要拿著這個(gè)ST去服務(wù)端再問一下,這個(gè)用戶給我的是有效的ST還是無效的ST,是有效的我才能讓這個(gè)用戶訪問。
OAuth2.0則是保障服務(wù)端的用戶資源的安全,獲取的最終信息是,我(OAuth2.0服務(wù)提供方)的用戶的資源到底能不能讓你(OAuth2.0的客戶端)訪問。
所以在最安全的模式下,用戶授權(quán)之后,服務(wù)端并不能直接返回token,通過重定向送給客戶端,因?yàn)檫@個(gè)token有可能被黑客截獲,如果黑客截獲了這個(gè)token,那用戶的資源也就暴露在這個(gè)黑客之下了。
于是聰明的服務(wù)端發(fā)送了一個(gè)認(rèn)證code給客戶端(通過重定向),客戶端在后臺(tái),通過https的方式,用這個(gè)code,以及另一串客戶端和服務(wù)端預(yù)先商量好的密碼,才能獲取到token和刷新token,這個(gè)過程是非常安全的。
如果黑客截獲了code,他沒有那串預(yù)先商量好的密碼,他也是無法獲取token的。這樣oauth2就能保證請(qǐng)求資源這件事,是用戶同意的,客戶端也是被認(rèn)可的,可以放心的把資源發(fā)給這個(gè)客戶端了
到此這篇關(guān)于入門到精通Java SSO單點(diǎn)登錄原理詳解的文章就介紹到這了,更多相關(guān)SSO單點(diǎn)登錄內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
關(guān)于bootstrap.yml和bootstrap.properties的優(yōu)先級(jí)問題
這篇文章主要介紹了關(guān)于bootstrap.yml和bootstrap.properties的優(yōu)先級(jí)問題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-03-03
springMVC框架下JQuery傳遞并解析Json數(shù)據(jù)
json作為一種輕量級(jí)的數(shù)據(jù)交換格式,在前后臺(tái)數(shù)據(jù)交換中占據(jù)著非常重要的地位,這篇文章主要介紹了springMVC框架下JQuery傳遞并解析Json數(shù)據(jù),有興趣的可以了解一下。2017-01-01
MyBatis-Plus數(shù)據(jù)權(quán)限插件的簡(jiǎn)單使用
在MyBatis-Plus中,通過DataPermissionInterceptor插件實(shí)現(xiàn)數(shù)據(jù)權(quán)限控制,首先需要?jiǎng)?chuàng)建自定義注解和處理類,利用JSQLParser庫(kù)動(dòng)態(tài)修改SQL,實(shí)現(xiàn)按角色權(quán)限過濾數(shù)據(jù),配置類中注冊(cè)攔截器,確保只有授權(quán)用戶能訪問指定數(shù)據(jù),感興趣的可以了解一下2024-10-10
淺談JDK8中的Duration Period和ChronoUnit
在JDK8中,引入了三個(gè)非常有用的時(shí)間相關(guān)的API:Duration,Period和ChronoUnit。他們都是用來對(duì)時(shí)間進(jìn)行統(tǒng)計(jì)的,本文將會(huì)詳細(xì)講解一下這三個(gè)API的使用2021-06-06
Java實(shí)現(xiàn)簡(jiǎn)易學(xué)生管理系統(tǒng)
這篇文章主要為大家詳細(xì)介紹了Java實(shí)現(xiàn)簡(jiǎn)易學(xué)生管理系統(tǒng),文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-07-07

