??大家好，我是陳哈哈。單點(diǎn)登錄SSO的出現(xiàn)是為了解決眾多企業(yè)面臨的痛點(diǎn)，場(chǎng)景即用戶需要登錄N個(gè)程序或系統(tǒng)，每個(gè)程序與系統(tǒng)都有不同的用戶名和密碼。在企業(yè)發(fā)展初期，可能僅僅有幾個(gè)程序時(shí)，管理賬戶和密碼不是一件難事。但是發(fā)展到有數(shù)十、百、千計(jì)的應(yīng)用程序時(shí)，縱然是千手觀音也是異常困難，畢竟腦子不是多線程。
??本文將從統(tǒng)一認(rèn)證中的
認(rèn)證與授權(quán)、SSO單點(diǎn)登錄、四種安全認(rèn)證協(xié)議、四種認(rèn)證協(xié)議比較幾個(gè)方面展開聊聊，希望對(duì)你有所收貨。
投稿素材：富貴人家的貓
作者：二凝
一、認(rèn)證與授權(quán)
?? 在開發(fā)的過程中，常常聽說認(rèn)證（Authentication）和授權(quán)（Authorization），它們的縮寫都為auth，所以非常容易混淆。
??Authentication 認(rèn)證（who am I ?）
例：給快遞小哥出示身份證證明你是你，小哥把快遞給你。
?? 認(rèn)證（Authentication）是驗(yàn)證用戶提供的或者存儲(chǔ)在系統(tǒng)的證書，證明用戶就是他們所說的人的過程。如果證書相符，就授予訪問權(quán)，如果不符，就拒絕訪問。
??Authorization 授權(quán)（what can i do ?）
例：你向快遞員出示了身份證，然后你又把你房門的密碼給了他，并告訴他說，我把房門密碼給你，你幫我放到我客廳里吧。
?? 授權(quán)指的是你被允許訪問應(yīng)用的某個(gè)區(qū)域或者運(yùn)行特定的行為，允許是建立在應(yīng)用的特定標(biāo)準(zhǔn)和條件下的。它也被稱為訪問控制或者權(quán)限控制。
?? 授權(quán)可以授予或者拒絕執(zhí)行任務(wù)、訪問應(yīng)用某些區(qū)域的權(quán)利。
二、統(tǒng)一認(rèn)證 - SSO單點(diǎn)登錄
??單點(diǎn)登錄英文全稱 Single Sign On，簡(jiǎn)稱 SSO。它的定義是：在多個(gè)應(yīng)用系統(tǒng)中，用戶只需要登錄一次，即可訪問所有相互信任的應(yīng)用系統(tǒng)。SSO 服務(wù)用于解決同一公司不同業(yè)務(wù)應(yīng)用之間的身份認(rèn)證問題，只需要登錄一次，即可訪問所有添加的應(yīng)用。
主流單點(diǎn)登錄SSO技術(shù)方案（安全認(rèn)證協(xié)議）包括下午五種：
- JWT單點(diǎn)登錄協(xié)議
- OpenID Connect (OIDC) 單點(diǎn)登錄協(xié)議
- OAuth 2.0單點(diǎn)登錄協(xié)議
- SAML 單點(diǎn)登錄協(xié)議
- CAS 單點(diǎn)登錄協(xié)議
??JWT協(xié)議
??Json web token （ JWT ）, 是一種用于雙方之間傳遞安全信息的簡(jiǎn)潔的表述性聲明規(guī)范。JWT作為一個(gè)開放的標(biāo)準(zhǔn)（RFC 7519），定義了一種簡(jiǎn)潔的方法用于通信雙方之間以 Json 對(duì)象的形式安全地傳遞信息，該 token被設(shè)計(jì)為緊湊且安全的，特別適用于分布式站點(diǎn)的單點(diǎn)登錄（SSO）場(chǎng)景。
??JWT優(yōu)勢(shì)
- 體積?。ㄒ淮址?。因而傳輸速度快；
- 傳輸方式多樣?？梢酝ㄟ^ HTTP 頭部（推薦）/URL/POST 參數(shù)等方式傳輸；
- 嚴(yán)謹(jǐn)?shù)慕Y(jié)構(gòu)化。它自身（在 payload 中）就包含了所有與用戶相關(guān)的驗(yàn)證消息，如用戶可訪問路由、訪問有效期等信息，服務(wù)器無需再去連接數(shù)據(jù)庫(kù)驗(yàn)證信息的有效性，并且 payload 支持應(yīng)用定制；
- 支持跨域驗(yàn)證。多應(yīng)用于單點(diǎn)登錄；
??JWT協(xié)議 - Token組成
token組成（xxxx.yyyy.zzzz）：
- Header
- Payload
- Signature
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VybmFtZSI6InRlc3QiLCJpYXQiOjE1OTM5NTU5NDMsInVpZCI6MTAsImV4cCI6MTU5Mzk1NTk3Mywic2NvcGVzIjpbImFkbWluIiwidXNlciJdfQ.
VHpxmxKVKpsn2Iytqc_6Z1U1NtiX3EgVki4PmA-J3Pg
??JWT協(xié)議 - Header
??Header通常由兩部分組成：令牌的類型（即JWT）和所使用的簽名算法(例如HMAC SHA256或RSA)。 例如：
{
"alg": "SHA256",
"typ": "JWT"
}
Header會(huì)被Base64Url編碼為JWT的第一部分。即為：
$ echo -n '{"alg":"HS256","typ":"JWT"}'|base64
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
??JWT協(xié)議 - Payload
??這些是一組預(yù)定義的權(quán)利要求，不是強(qiáng)制性的，而是建議使用的，以提供一組有用的可互操作的權(quán)利要求。其中一些是： iss（JWT的簽發(fā)者）， exp（expires,到期時(shí)間）， sub（主題）， aud（JWT接收者），iat(issued at，簽發(fā)時(shí)間)，nbf（在此之前不可用），jti（JWT ID用于標(biāo)識(shí)該JWT）等。
{ "iat": 1593955943,
"exp": 1593955973,
"uid": 10,
"username": "test",
"scopes": [ "admin", "user" ]
}
Payload會(huì)被Base64Url編碼為JWT的第二部分。即為：
$ echo -n '{"iat":1593955943,"exp":1593955973,"uid":10,"username":"test","scopes":["admin","user"]}'|base64
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
eyJ1c2VybmFtZSI6InRlc3QiLCJpYXQiOjE1OTM5NTU5NDMsInVpZCI6MTAsImV4cCI6MTU5Mzk1NTk3Mywic2NvcGVzIjpbImFkbWluIiwidXNlciJdfQ
??JWT協(xié)議 - Signature
??Signature部分的生成需要base64編碼之后的Header,base64編碼之后的Payload,密鑰（secret）,Header需要指定簽字的算法。
Signature：
HMACSHA256(base64UrlEncode(header) + “.” +base64UrlEncode(payload),secret)
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VybmFtZSI6InRlc3QiLCJpYXQiOjE1OTM5NTU5NDMsInVpZCI6MTAsImV4cCI6MTU5Mzk1NTk3Mywic2NvcGVzIjpbImFkbWluIiwidXNlciJdfQ.
VHpxmxKVKpsn2Iytqc_6Z1U1NtiX3EgVki4PmA-J3Pg
??OAuth2協(xié)議
??OAuth（Open Authorization）是一個(gè)關(guān)于授權(quán)（authorization）的開放網(wǎng)絡(luò)標(biāo)準(zhǔn)，允許用戶授權(quán)第三方應(yīng)用訪問他們存儲(chǔ)在另外的服務(wù)提供者上的信息，而不需要將用戶名和密碼提供給第三方移動(dòng)應(yīng)用或分享他 們數(shù)據(jù)的所有內(nèi)容。OAuth在全世界得到廣泛應(yīng)用，目前的版本是2.0版。
??OAuth2協(xié)議 - 應(yīng)用場(chǎng)景
- 原生app授權(quán)：app登錄請(qǐng)求后臺(tái)接口，為了安全認(rèn)證，所有請(qǐng)求都帶token信息，如果登錄驗(yàn)證、 請(qǐng)求后臺(tái)數(shù)據(jù)。
- 前后端分離單頁(yè)面應(yīng)用：前后端分離框架，前端請(qǐng)求后臺(tái)數(shù)據(jù)，需要進(jìn)行oauth2安全認(rèn)證。
- 第三方應(yīng)用授權(quán)登錄，比如QQ，微博，微信的授權(quán)登錄。
??OAuth2協(xié)議 - 協(xié)議特點(diǎn)
- 簡(jiǎn)單：不管是OAuth服務(wù)提供者還是應(yīng)用開發(fā)者，都很易于理解與使用；
- 安全：沒有涉及到用戶密鑰等信息，更安全更靈活；
- 開放：任何服務(wù)提供商都可以實(shí)現(xiàn)OAuth，任何軟件開發(fā)商都可以使用OAuth；
??OAuth2協(xié)議 - 授權(quán)模式
??客戶端必須得到用戶的授權(quán)（authorization grant），才能獲得令牌（access token）。OAuth 2.0一共分成四種授權(quán)類型（authorization grant）
授權(quán)碼模式（authorization code）- 簡(jiǎn)化模式（implicit）
- 密碼模式（resource owner password credentials）
- 客戶端模式（client credentials）
??授權(quán)碼模式和密碼模式比較常用。
??第三方應(yīng)用申請(qǐng)令牌之前，都必須先到系統(tǒng)備案，說明自己的身份，然后會(huì)拿到兩個(gè)身份識(shí)別碼：客戶端 ID（client ID）和客戶端密鑰（client secret）。這是為了防止令牌被濫用，沒有備案過的第三方應(yīng)用，是不會(huì)拿到令牌的。
??OpenID Connect協(xié)議
??OpenID Connect簡(jiǎn)稱為OIDC，是基于OAuth2.0擴(kuò)展出來的一個(gè)協(xié)議。 它在OAuth2上構(gòu)建了一個(gè)身份層用于認(rèn)證，是一個(gè)基于OAuth2協(xié)議的身份認(rèn)證標(biāo)準(zhǔn)協(xié)議。可以說OIDC協(xié)議是當(dāng)今最流行的協(xié)議。
??OAuth2實(shí)際上只做了授權(quán)，而OpenID Connect在授權(quán)的基礎(chǔ)上又加上了認(rèn)證。
??OIDC的優(yōu)點(diǎn)是：簡(jiǎn)單的基于JSON的身份令牌（JWT），并且完全兼容OAuth2協(xié)議。
OpenID（認(rèn)證）+
OAuth 2.0（授權(quán)）=OpenID Connect（認(rèn)證+授權(quán)）
??OIDC協(xié)議的登陸授權(quán)流程和OAuth2.0基本類似, 整個(gè)流程的參與者也類似，相比OAuth2，OIDC引入了id_token等和userinfo相關(guān)的概念：
- 整個(gè)OAuth2協(xié)議，只是定義了access_token/refresh_token，但是這倆token只是為了保護(hù)Resource Server的，并沒有Resource Owner的身份信息；
- OIDC引入了id_token的概念，用這個(gè)特殊的token來表示這是Resource Owner的身份證;
- 標(biāo)準(zhǔn)化id_token的格式：即大家熟知的JWT；
- 標(biāo)準(zhǔn)化id_token的內(nèi)容：Standard Claims
- OIDC引入了關(guān)于如何獲取詳細(xì)userinfo的Endpoint；
??OpenID Connect協(xié)議 - IDToken的意義
- 在access token添加用戶身份信息，可能導(dǎo)致用戶信息泄露；
??因?yàn)槊看谓涌谡?qǐng)求都攜帶access token，其payload部分的用戶信息是可解析的，相當(dāng)于是明文的；
-
access token目的是用于接口訪問的憑證，如果同時(shí)包含用戶信息的話，功能就不分離了；
-
使用idToken替換userinfo endpoint獲取用戶信息，減少請(qǐng)求開銷；
??一般oauth2協(xié)議，都提供userinfo endpoint獲取用戶信息，例微軟：https://graph.microsoft.com/oidc/userinfo，使用access token調(diào)用此接口獲取得到用戶信息；idToken可節(jié)省調(diào)用userinfo API接口的額外消耗；
- 某些場(chǎng)景，如只需要用戶登錄認(rèn)證并獲取用戶信息，而不必調(diào)用Resource Server的其他API；那么這種場(chǎng)景只需要返回idToken，accessToken將不必返回；
??從權(quán)限范圍方面來看：OAuth2 > OpenID Connect。
??現(xiàn)在很多網(wǎng)站都提供了「使用微信快速認(rèn)證」（也就是 OAuth2 ）作為登錄方式。但當(dāng)你不確定這個(gè)網(wǎng)站是否可信時(shí)，這樣做是危險(xiǎn)的。因?yàn)?OAuth2授權(quán)登錄后，就相當(dāng)于把你微信的部分?jǐn)?shù)據(jù)（比如名稱、圖像、手機(jī)號(hào)）和權(quán)利（比如發(fā)私信）交給了這個(gè)網(wǎng)站，至于網(wǎng)站要做什么你根本不知道。
??而 OpenID Connect 只是告訴網(wǎng)站或別人，這個(gè)帳號(hào)是你而已，并不會(huì)也無法提供其它數(shù)據(jù)。
??SAML協(xié)議
??SAML 是 Security Assertion Markup Language 的簡(jiǎn)稱，是一種基于XML的開放標(biāo)準(zhǔn)協(xié)議，用于在身份提供者（Identity Provider簡(jiǎn)稱IDP）和服務(wù)提供商（Service Provider簡(jiǎn)稱SP）之間交換認(rèn)證和授權(quán)數(shù)據(jù)。
- IDP：賬號(hào)認(rèn)證的服務(wù)方（統(tǒng)一認(rèn)證）
- SP：向用戶提供商業(yè)服務(wù)的軟件（實(shí)體），比如全預(yù)約子系統(tǒng)
- User Agent：web瀏覽器
- 用戶試圖登錄 SP 提供的應(yīng)用。
- SP 生成 SAML Request，通過瀏覽器重定向，向 IdP 發(fā)送 SAML Request。
- IdP 解析 SAML Request 并將用戶重定向到認(rèn)證頁(yè)面。
- 用戶在認(rèn)證頁(yè)面完成登錄。
- IdP 生成 SAML Response，通過對(duì)瀏覽器重定向，向 SP 的 ACS 地址返回 SAML Response，其中包含 SAML Assertion 用于確定用戶身份。
- SP 對(duì) SAML Response 的內(nèi)容進(jìn)行檢驗(yàn)。
- 用戶成功登錄到 SP 提供的應(yīng)用。
??在第一步，SP將會(huì)對(duì)該資源進(jìn)行相應(yīng)的安全檢查，如果發(fā)現(xiàn)瀏覽器中存在有效認(rèn)證信息并驗(yàn)證通過，SP將會(huì)跳過2-6步，直接進(jìn)入第7步。
??如果在第一步的時(shí)候，SP并沒有在瀏覽器中找到相應(yīng)的有效認(rèn)證信息的話，則會(huì)生成對(duì)應(yīng)的SAMLRequest，并將User Agent重定向到IdP。
??SAML協(xié)議 - 參數(shù)
??SAML協(xié)議 - SAML的缺點(diǎn)
- 協(xié)議復(fù)雜：SAML協(xié)議的文檔較大，用戶可能需要更多的時(shí)間來理解協(xié)議，熟悉它的使用方法。
- 實(shí)施成本偏高：SAML需要積極支持Security Assertion Markup Language (SAML)的服務(wù)器軟件，而這些服務(wù)器軟件的安裝和配置可能比較昂貴。
- 手機(jī)APP中兼容性較差：SAML需要通過HTTP Redect和HTTP POST協(xié)議來傳遞用戶信息，并且通常是通過FORM表單的格式來進(jìn)行數(shù)據(jù)的提交的。
??CAS協(xié)議
??CAS全稱為Central Authentication Service即中央認(rèn)證服務(wù)，是一個(gè)企業(yè)多語(yǔ)言單點(diǎn)登錄的解決方案，并努力去成為一個(gè)身份驗(yàn)證和授權(quán)需求的綜合平臺(tái)。
- CAS Server需要獨(dú)立部署，主要負(fù)責(zé)對(duì)用戶的認(rèn)證工作；
- CAS Client負(fù)責(zé)處理對(duì)客戶端受保護(hù)資源的訪問請(qǐng)求，若需要登錄，重定向到CAS Server。
??CAS協(xié)議 - 認(rèn)證過程：
- 用戶訪問應(yīng)用系統(tǒng)，應(yīng)用系統(tǒng)需要用戶認(rèn)證，則重定向到CAS服務(wù)器；
- 用戶在CAS服務(wù)器上輸入用戶名和密碼，CAS服務(wù)器驗(yàn)證用戶賬號(hào)和密碼；
- 驗(yàn)證成功后，CAS服務(wù)器生成一個(gè)Ticket，并重定向回應(yīng)用系統(tǒng)；
- 應(yīng)用系統(tǒng)拿著Ticket去CAS服務(wù)器上驗(yàn)證，驗(yàn)證成功后，CAS服務(wù)器返回一個(gè)有效的用戶賬號(hào)（可以是用戶名、郵箱等）；
- 應(yīng)用系統(tǒng)使用返回的用戶賬號(hào)進(jìn)行本地的用戶認(rèn)證，認(rèn)證成功后，用戶即可登錄應(yīng)用系統(tǒng)。
??CAS協(xié)議 - 授權(quán)過程：
- 用戶登錄應(yīng)用系統(tǒng)后，需要訪問某個(gè)資源；
- 應(yīng)用系統(tǒng)將用戶的訪問請(qǐng)求發(fā)送到CAS服務(wù)器，并攜帶用戶的身份信息；
- CAS服務(wù)器驗(yàn)證用戶的身份信息，并根據(jù)用戶的權(quán)限，判斷用戶是否有權(quán)訪問該資源；
- CAS服務(wù)器返回授權(quán)結(jié)果給應(yīng)用系統(tǒng)；
- 應(yīng)用系統(tǒng)根據(jù)CAS服務(wù)器返回的授權(quán)結(jié)果，決定是否允許用戶訪問該資源。
??用戶訪問不同語(yǔ)言、不同架構(gòu)的服務(wù)，服務(wù)又通過CAS、SAML、Oauth等協(xié)議與認(rèn)證服務(wù)器進(jìn)行交互，基于spring mvc框架的認(rèn)證服務(wù)器從LDAP、數(shù)據(jù)庫(kù)、或AD獲取數(shù)據(jù)對(duì)用戶進(jìn)行身份驗(yàn)證，然后向用戶頒發(fā)憑據(jù)。
??當(dāng)前版本的CAS集成的身份驗(yàn)證機(jī)制有AD、Generic、LDAP、JDBC等等，由于發(fā)展的需要，現(xiàn)在的CAS已經(jīng)支持其他的一些身份協(xié)議，例如OIDC、Oauth 2.0等等。
三、四種認(rèn)證協(xié)議比較
??將OIDC、OAuth 2.0、SAML2、CAS 3.0 四種標(biāo)準(zhǔn)認(rèn)證協(xié)議做一個(gè)具體對(duì)比：文章來源：http://www.zghlxwxcb.cn/news/detail-727515.html
文章來源地址http://www.zghlxwxcb.cn/news/detail-727515.html
到了這里，關(guān)于聊聊統(tǒng)一認(rèn)證中的四種安全認(rèn)證協(xié)議（干貨分享）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
