Identity Server 4 预备知识 -- OpenID Connect 简介
我之前的文章簡(jiǎn)單的介紹了OAuth 2.0 (在這里:?要用Identity Server 4 -- OAuth 2.0 超級(jí)簡(jiǎn)介, 還不是很全.
這篇文章我要介紹一下 OpenID Connect.
OAuth 2.0 不是身份認(rèn)證協(xié)議
OAuth 2.0 不是身份認(rèn)證(Authentication)協(xié)議. 為什么有人會(huì)認(rèn)為OAuth 2.0具有身份認(rèn)證的功能? 這是因?yàn)镺Auth2經(jīng)常作為身份認(rèn)證(Authentication)協(xié)議的一部分來(lái)使用. 例如在典型的OAuth2流程里, OAuth2經(jīng)常會(huì)嵌入一些身份認(rèn)證的事件.
那么身份認(rèn)證(Authentication)是什么?
我們這里所說(shuō)的身份認(rèn)證就是指它可以告訴應(yīng)用程序當(dāng)前的用戶是誰(shuí), 還有這些用戶是否正在使用你的應(yīng)用程序. 它是一種安全架構(gòu), 它可以告訴你用戶是他們所聲明的身份, 通常呢, 是通過(guò)提供一套安全憑據(jù)(例如用戶名和密碼)給應(yīng)用程序來(lái)證明這一點(diǎn).
而OAuth2則不管用戶這些東西, OAuth2的客戶端應(yīng)用只考慮請(qǐng)求token, 得到token, 使用token訪問(wèn)API. 它不關(guān)心誰(shuí)給客戶端應(yīng)用授權(quán)了, 也不關(guān)心是否有最終用戶.\
?
身份認(rèn)證(Authentication) vs 授權(quán)(Authorization)
引用《OAuth 2.0 in Action》里面的一個(gè)比喻來(lái)解釋, 把身份認(rèn)證看作是軟糖, 而授權(quán)是巧克力. 這兩種東西感覺(jué)略有相似, 但是本質(zhì)上卻截然不同:?巧克力是一種原料, 而軟糖是一種糖果. 可以使用巧克力作為主要原料做出巧克力口味的糖果, 但是巧克力和軟糖絕不是等價(jià)的.
盡管巧克力可以單獨(dú)作為一種最終產(chǎn)品, 但在這個(gè)比喻里巧克力是一種非常有用原料, 它極具多樣性, 可以用來(lái)做蛋糕, 冰激凌, 雪糕等等.
?
在這個(gè)比喻里?OAuth 2.0?就是巧克力, 它是眾多web安全架構(gòu)的一種多用途的基本成分.
而軟糖, 是一種糖果. 有一種特別可口的軟糖叫做巧克力軟糖. 很顯然, 巧克力在這種軟糖里是主要成分, 但是它還需要其它原料成分和一些關(guān)鍵的流程把巧克力轉(zhuǎn)化成巧克力軟糖.
制做出的產(chǎn)品是軟糖的形式, 它以巧克力為主要成分. 這叫使用巧克力來(lái)制作軟糖, 所以說(shuō)巧克力不等價(jià)于軟糖.
在這個(gè)比喻里,?身份認(rèn)證就更像軟糖, 它需要一些關(guān)鍵的組件和流程, 而卻要把這些組件和流程通過(guò)正確的組合起來(lái)并安全的使用, 針對(duì)這些組件和流程還是有很多的選項(xiàng)的.
可以說(shuō)我們要制作巧克力軟糖, 也就是需要一個(gè)基于OAuth2的身份認(rèn)證協(xié)議. 而OpenID Connect就是這樣的開(kāi)放標(biāo)準(zhǔn), 它可以工作于不同的身份供應(yīng)商之間.?OpenID Connect 基于 OAuth 2.0, 在此之上, 它添加了一些組件來(lái)提供身份認(rèn)證的能力.
?
OpenID Connect的官方定義是:?OpenID Connect是建立在OAuth 2.0協(xié)議上的一個(gè)簡(jiǎn)單的身份標(biāo)識(shí)層, OpenID Connect 兼容 OAuth 2.0.?
?
OAuth 2.0與身份認(rèn)證協(xié)議的角色映射
想要基于OAuth2構(gòu)建身份認(rèn)證協(xié)議, 那么就需要把OAuth2里面的那些角色映射到身份認(rèn)證的事務(wù)里面.
在OAuth2里面, 資源所有者(Resource Owner)和客戶端應(yīng)用(Client)經(jīng)常在一起工作, 因?yàn)榭蛻舳藨?yīng)用代表了資源所有者. 而授權(quán)服務(wù)器(Authorization Server)和被保護(hù)的資源(Protected Resource)經(jīng)常在一起, 因?yàn)槭跈?quán)服務(wù)器生成token, 而被保護(hù)的資源接收token. 所以說(shuō)在最終用戶/客戶端應(yīng)用 與 授權(quán)服務(wù)器/被保護(hù)資源 之前存在一個(gè)安全和信任的邊界, 而OAuth2就是用來(lái)跨越這個(gè)邊界的協(xié)議.
而在身份認(rèn)證的事務(wù)里, 最終用戶使用身份提供商(Identity Provider, IdP)登錄到依賴方(Relying Party, RP, 可以理解為客戶端).
總結(jié)一下前面這段話:
OAuth2里可以分為兩部分: 1.資源所有者/客戶端應(yīng)用, 2.授權(quán)服務(wù)器/被保護(hù)資源.
身份認(rèn)證協(xié)議里也是兩大部分: 1.依賴方,?2.身份提供商.
所以考慮這樣映射:
OAuth2里的授權(quán)服務(wù)器/被保護(hù)資源 ---- 身份認(rèn)證協(xié)議里的身份提供商進(jìn)行映射
OAuth2里面的資源所有者 ---- 身份認(rèn)證協(xié)議里的最終用戶
OAuth2的客戶端應(yīng)用 ---- 身份認(rèn)證協(xié)議里的依賴方(RP).
OAuth2里, 資源所有者的權(quán)限會(huì)委派給客戶端應(yīng)用, 但這時(shí)該權(quán)限對(duì)應(yīng)的被保護(hù)資源就是他們自己的身份信息. 也就是說(shuō)他們授權(quán)給依賴方(RP), 讓其可以知道現(xiàn)在是誰(shuí)在使用應(yīng)用, 而這就是身份認(rèn)證事務(wù)本質(zhì).
依賴方現(xiàn)在就可以知道是誰(shuí)在使用系統(tǒng)并且他們是如何登錄進(jìn)來(lái)的. 不過(guò)這里還需要用到另外一種token, 叫做ID token, 這種token攜帶著身份認(rèn)證事件本身的信息.
那么為什么不使用OAuth2里的access token把這些事都一次性解決了呢??
因?yàn)槭紫萢ccess token不含有任何關(guān)于身份認(rèn)證的信息; 其次access token的生命期可能會(huì)非常的長(zhǎng), 即使用戶離開(kāi)了它仍有可能有效, 它還有可能被用于無(wú)最終用戶參與的情況; 還有一種情況就是access token可能會(huì)被其它的客戶端應(yīng)用借用. 所以, 無(wú)論客戶端是如何得到的access token, 它都無(wú)法從access token里得到最終用戶的信息以及最終用戶的身份認(rèn)證狀態(tài).
在OAuth2里, access token不是為客戶端準(zhǔn)備的, 它對(duì)于客戶端應(yīng)該是不透明的, 但是客戶端也需要從access token得到一些用戶信息. 實(shí)際上客戶端應(yīng)用只是access token的展示者, access token真正的目標(biāo)觀眾是被保護(hù)的資源.
在OpenID Connect里, 這個(gè)第二個(gè)叫做ID Token, 它會(huì)和access token一同發(fā)送給客戶端應(yīng)用.
?
OpenID Connect
OpenID Connect是由OpenID基金會(huì)于2014年發(fā)布的一個(gè)開(kāi)放標(biāo)準(zhǔn), 簡(jiǎn)單的說(shuō)就是, 它使用OAuth2來(lái)進(jìn)行身份認(rèn)證. OpenID Connect直接構(gòu)建于OAuth2.0的基礎(chǔ)之上, 與其兼容. 通常OpenID Connect是和OAuth2一同部署來(lái)使用的.
?
OpenID Connect的整體抽象流程如下圖所示:?
1. 依賴發(fā)(RP)發(fā)送請(qǐng)求到OpenID提供商(OP, 也就是身份提供商).
2. OpenID提供商驗(yàn)證最終用戶的身份, 并獲得了用戶委派的授權(quán)
3. OpenID提供商返回響應(yīng), 里面帶著ID Token, 也通常帶著Access Token.
4. 依賴方現(xiàn)在可以使用Access Token發(fā)送請(qǐng)求到用戶信息的端點(diǎn).
5. 用戶信息端點(diǎn)返回用戶的聲明(claims, 相當(dāng)于是用戶的信息).
?
OpenID Connect的ID Token 和用戶信息端點(diǎn)以后在使用Identity Server 4的時(shí)候在進(jìn)行介紹.
?
身份認(rèn)證
OpenID Connect 會(huì)負(fù)責(zé)身份認(rèn)證這個(gè)動(dòng)作, 也就是把最終用戶登錄到系統(tǒng), 或者判斷最終用戶是否已經(jīng)登錄了. OpenID Connect會(huì)通過(guò)一種安全的方式從服務(wù)器把身份認(rèn)證的結(jié)果返回給客戶端, 這樣客戶端就可以依賴于它了. 也是因?yàn)檫@個(gè)原因, 客戶端被稱為了依賴方(RP).?這個(gè)身份認(rèn)證的結(jié)果就是ID Token.
OpenID Connect身份認(rèn)證有三個(gè)路徑(三個(gè)流程, flow):?Authorization Code 流程,?Implicit 流程,?Hybrid 流程.
?
Authorization Code Flow
在Authorization Code 流程里, 一個(gè)授權(quán)碼(Authorization Code)會(huì)被返回給客戶端. 這個(gè)授權(quán)碼可以被直接用來(lái)交換ID Token和Access Token. 該流程也可以在客戶端使用授權(quán)碼兌換Access Token之前對(duì)其身份認(rèn)證. 但是該流程要求客戶端的身份認(rèn)證動(dòng)作在后臺(tái)使用client id和secret來(lái)獲得tokens, 這樣就不會(huì)把tokens暴露給瀏覽器或其它可訪問(wèn)瀏覽器的惡意應(yīng)用了.
這種流程要求客戶端應(yīng)用可以安全的在它和授權(quán)服務(wù)器之間維護(hù)客戶端的secret, 也就是說(shuō)只適合這樣的客戶端應(yīng)用.
它還適合于長(zhǎng)時(shí)間的訪問(wèn)(通過(guò)refresh token).
Authorization Code流程的授權(quán)碼來(lái)自于授權(quán)端點(diǎn), 而所有的tokens都來(lái)自于Token端點(diǎn).?
Authorization Code流程的步驟如下:
客戶端準(zhǔn)備身份認(rèn)證請(qǐng)求, 請(qǐng)求里包含所需的參數(shù)
客戶端發(fā)送請(qǐng)求到授權(quán)服務(wù)器
授權(quán)服務(wù)器對(duì)最終用戶進(jìn)行身份認(rèn)證
授權(quán)服務(wù)器獲得最終用戶的同意/授權(quán)
授權(quán)服務(wù)器把最終用戶發(fā)送回客戶端, 同時(shí)帶著授權(quán)碼
客戶端使用授權(quán)碼向Token端點(diǎn)請(qǐng)求一個(gè)響應(yīng)
客戶端接收到響應(yīng), 響應(yīng)的body里面包含著ID Token 和 Access Token
客戶端驗(yàn)證ID Token, 并獲得用戶的一些身份信息.
?
Implicit Flow
Implicit流程在請(qǐng)求token的時(shí)候不需要明確的客戶端身份認(rèn)證, 它使用重定向URI的方式來(lái)驗(yàn)證客戶端的身份. 因?yàn)檫@一點(diǎn), refresh token也就無(wú)法使用了, 這同樣也不適合于長(zhǎng)時(shí)間有效的access token.
在Implicit流程里, 所有的tokens都來(lái)自于授權(quán)端點(diǎn), 而Token端點(diǎn)并沒(méi)有用到.
該流程主要用于瀏覽器內(nèi)的應(yīng)用, Access Token和ID Token一同被直接返回給客戶端. 因?yàn)檫@個(gè)原因, 這些tokens也會(huì)暴露于最終用戶和可以訪問(wèn)該瀏覽器的其它應(yīng)用了.?
它并不適合于長(zhǎng)時(shí)間的訪問(wèn).
Implicit流程的步驟如下:
客戶端準(zhǔn)備身份認(rèn)證請(qǐng)求, 請(qǐng)求里包含所需的參數(shù)
客戶端發(fā)送請(qǐng)求到授權(quán)服務(wù)器
授權(quán)服務(wù)器對(duì)最終用戶進(jìn)行身份認(rèn)證
授權(quán)服務(wù)器獲得最終用戶的同意/授權(quán)
授權(quán)服務(wù)器把最終用戶發(fā)送回客戶端, 同時(shí)帶著ID Token. 如果也請(qǐng)求了Access Token的話, 那么Access Token也會(huì)一同返回.
客戶端驗(yàn)證ID Token, 并獲得用戶的一些身份信息.
?
Hybrid Flow
Hybrid流程是前兩者的混合, 在該流程里, 有一些tokens和授權(quán)碼來(lái)自于授權(quán)端點(diǎn), 而另外一些tokens則來(lái)自于Token端點(diǎn).
該流程允許客戶端立即使用ID Token, 并且只需要一次往返即可獲得授權(quán)碼.
這種流程也要求客戶端應(yīng)用可以安全的維護(hù)secret.
它也適合于長(zhǎng)時(shí)間的訪問(wèn).
Hybrid流程的步驟如下:
客戶端準(zhǔn)備身份認(rèn)證請(qǐng)求, 請(qǐng)求里包含所需的參數(shù)
客戶端發(fā)送請(qǐng)求到授權(quán)服務(wù)器
授權(quán)服務(wù)器對(duì)最終用戶進(jìn)行身份認(rèn)證
授權(quán)服務(wù)器獲得最終用戶的同意/授權(quán)
授權(quán)服務(wù)器把最終用戶發(fā)送回客戶端, 同時(shí)帶著授權(quán)碼, 根據(jù)響應(yīng)類型的不同, 也可能還帶著一個(gè)或者多個(gè)其它的參數(shù).
客戶端使用授權(quán)碼向Token端點(diǎn)請(qǐng)求一個(gè)響應(yīng)
客戶端接收到響應(yīng), 響應(yīng)的body里面包含著ID Token 和 Access Token
客戶端驗(yàn)證ID Token, 并獲得用戶的一些身份信息.
?
三種流程特點(diǎn)的比較:
| 所有的tokens都來(lái)自于授權(quán)端點(diǎn) | no | yes | no |
| 所有的tokens都來(lái)自于Token端點(diǎn) | yes | no | no |
| Tokens對(duì)瀏覽器隱藏 | yes | no | no |
| 客戶端可以被認(rèn)證 | yes | no | yes |
| 可以使用Refresh Token | yes | no | yes |
| 只需一次往返通信 | no | yes | no |
| 大部分通信都是服務(wù)器對(duì)服務(wù)器 | yes | no | 看情況 |
?
返回類型值的比較:?
| code? | Authorization Code Flow |
| id_token? | Implicit Flow |
| id_token?token? | Implicit Flow |
| code?id_token? | Hybrid Flow |
| code?token? | Hybrid Flow |
| code?id_token?token? | Hybrid Flow |
?
本文就簡(jiǎn)單介紹這些, OAuth 2.0 和 OpenID Connect 其余涉及到的內(nèi)容會(huì)在后續(xù)Identity Server 4的系列文章里介紹.
原文地址：https://www.cnblogs.com/cgzl/p/9231219.html
.NET社區(qū)新聞，深度好文，歡迎訪問(wèn)公眾號(hào)文章匯總 http://www.csharpkit.com
總結(jié)
以上是生活随笔為你收集整理的Identity Server 4 预备知识 -- OpenID Connect 简介的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： EntityFramework Core
- 下一篇： Ocelot.JwtAuthorize：