要用Identity Server 4 -- OAuth 2.0 超级简介
OAuth 2.0 簡介
OAuth有一些定義:
OAuth 2.0是一個(gè)委托協(xié)議, 它可以讓那些控制資源的人允許某個(gè)應(yīng)用以代表他們來訪問他們控制的資源, 注意是代表這些人, 而不是假冒或模仿這些人. 這個(gè)應(yīng)用從資源的所有者那里獲得到授權(quán)(Authorization)和access token, 隨后就可以使用這個(gè)access token來訪問資源.
(這里提到的假冒或模仿就是指在客戶端復(fù)制一份用戶名和密碼，從而獲取相應(yīng)的權(quán)限)。
OAuth 2.0是一個(gè)開放的協(xié)議, 它允許使用簡單和標(biāo)準(zhǔn)的方法從Web, 移動(dòng)或桌面應(yīng)用來進(jìn)行安全的授權(quán)(Authorization).
?
從這些定義可以看出來, OAuth2 是關(guān)于授權(quán)(Authorization)的,? 客戶端應(yīng)用可以請求access token, 使用這個(gè)token就可以訪問API資源了.
因?yàn)橛泻芏喾N類客戶端應(yīng)用的存在, 例如ASP.NET Core MVC, Angular, WPF 等等, 它們都是不同的應(yīng)用類型, 所以, OAuth2 定義了不同類型的客戶端應(yīng)用應(yīng)該如何安全的完成授權(quán).?OAuth2標(biāo)準(zhǔn)還定義了一些端點(diǎn), 并且定義了針對不同類型的客戶端應(yīng)用如何使用這些端點(diǎn).
Identity Server 4?和 Azure AD 都實(shí)現(xiàn)了OAuth 2.0 標(biāo)準(zhǔn).
但是上面提到的access token只能用來訪問資源, 它無法被用來登錄客戶端應(yīng)用. 登錄這種操作叫做認(rèn)證/身份驗(yàn)證(Authentication), 而OpenID Connect則可以完成這項(xiàng)工作.
?
OpenID Connect 簡介
OpenID Connect是建立在OAuth2協(xié)議上的一個(gè)簡單的身份標(biāo)識(shí)層, 所以O(shè)penID Connect兼容OAuth2.?
使用OpenID Connect, 客戶端應(yīng)用可以請求一個(gè)叫identity token的token, 它會(huì)和access token一同返回給客戶端應(yīng)用. 這個(gè)identity token就可以被用來登錄客戶端應(yīng)用程序, 而這個(gè)客戶端應(yīng)用還可以使用access token來訪問API資源.
OpenID Connect還定義了一個(gè)UserInfo端點(diǎn), (OAuth2定義了Authorization端點(diǎn)和Token端點(diǎn))它允許客戶端應(yīng)用獲取用戶的額外信息.?
此外它還定義了不同類型的應(yīng)用如何從身份識(shí)別提供商(IDP)安全的獲取這些token.
?
綜上,?OpenID Connect是更高級(jí)的協(xié)議, 它擴(kuò)展并替代了OAuth2. 盡管現(xiàn)在我們經(jīng)常說我們在使用OAuth2來保護(hù)API, 其實(shí)更準(zhǔn)確的說, 大多數(shù)情況下, 我們使用的是OpenID Connect.
?
如果到現(xiàn)在還是不明白OAuth2和OpenID Connect也沒關(guān)系, 這不是幾句話就能描述清楚的東西. 本文我進(jìn)一步介紹OAuth 2.0.
?
OAuth 2.0 進(jìn)一步介紹
OAuth2的目標(biāo)就是讓客戶端應(yīng)用可以代表資源所有者(通常是用戶)來訪問被保護(hù)的資源:
這里的資源所有者(Resource Owner), 他擁有訪問API資源的權(quán)限, 并且他還可以委派權(quán)限(delegate)給其他應(yīng)用來訪問API. 資源所有者通常是可以使用瀏覽器的人.
被保護(hù)的資源(Protected Resource)就是資源所有者擁有權(quán)限去訪問的組件, 它可以是很多種形式的, 但是web API的形式還是最常見的.
客戶端(Client)應(yīng)用就是代表資源所有者訪問被保護(hù)資源的一個(gè)軟件. 注意它既不是指瀏覽器, 也不是指給你錢讓你開發(fā)軟件的人. 在OAuth2里面, 它是指被保護(hù)的API資源的消費(fèi)者.
?
委拖/委派權(quán)限
前面提到OAuth2里面, 最終用戶可以委派他的一部分權(quán)限給客戶端應(yīng)用來代表最終用戶來訪問被保護(hù)的資源. 但是要完成這件事, 還需要一個(gè)橋梁來連接客戶端應(yīng)用和被保護(hù)資源. 這個(gè)組件叫做授權(quán)服務(wù)器(Authorization Server, AS). 這個(gè)授權(quán)服務(wù)器也許就是資源服務(wù)器, 但是大多數(shù)情況下它們是不同的服務(wù)器.
授權(quán)服務(wù)器(AS)是被受保護(hù)的資源所信任的, 它可以發(fā)行具有特定目的的安全憑據(jù)給客戶端應(yīng)用, 這個(gè)憑據(jù)叫做OAuth的?access token.
想要獲得access token, 客戶端應(yīng)用首先要把資源所有者發(fā)送給授權(quán)服務(wù)器
首先客戶端需要獲得權(quán)限, 它可能有兩種方式來獲得權(quán)限: 可以從資源所有者那里直接獲得權(quán)限, 也可以讓授權(quán)服務(wù)器作為中介, 從授權(quán)服務(wù)器那里間接的獲得權(quán)限. (上面這個(gè)圖中描述的是從資源授權(quán)者直接獲得權(quán)限的流程).
如果使用授權(quán)服務(wù)器作為中介的話, 客戶端需要把資源所有者發(fā)送到授權(quán)服務(wù)器(可以理解為最終用戶使用的瀏覽器被重定向到了授權(quán)服務(wù)器), 然后資源所有者在這可以對客戶端應(yīng)用進(jìn)行授權(quán).?
這時(shí)資源所有者要通過身份認(rèn)證進(jìn)入授權(quán)服務(wù)器, 通常還會(huì)有一個(gè)是否同意授權(quán)客戶端應(yīng)用請求的選項(xiàng), 點(diǎn)擊同意后就授權(quán)了. 而從客戶端應(yīng)用的角度講呢, 它可以向資源所有者請求他一部分的功能和范圍(scope), 在將來, 資源所有者可能會(huì)逐漸減少它所擁有的功能和范圍.
到這里, 上面寫的這個(gè)動(dòng)作/東西叫做授權(quán)(authorization grant).
一旦執(zhí)行了授權(quán)動(dòng)作也就是客戶端得到了授權(quán)(這個(gè)授權(quán)是一個(gè)可以代表資源所有者權(quán)限的憑據(jù)), 客戶端便可以從授權(quán)服務(wù)器請求access token了. 這個(gè)access token就可以被用來訪問被保護(hù)的資源了.
下圖是使用授權(quán)服務(wù)器作為中介的流程圖, 除了授權(quán), 其它部分和上圖表達(dá)的都是一個(gè)意思:
?
授權(quán) Authorization Grant
授權(quán) (authorization grant) 是一個(gè)代表著資源所有者權(quán)限的憑據(jù), 它可以被客戶端應(yīng)用來獲取access token. OAuth2里面定義了4種類型的授權(quán), 分別是:?auhtorization code,?implicit,?resource owner password credentials,?client credentials. OAuth2還定義了一個(gè)擴(kuò)展機(jī)制以便定義其它的授權(quán)類型.?
用一句話描述就是, 授權(quán)(Authorization Grant)就是獲取token的方法.
1. Authorization Code
Authorization Code是使用授權(quán)服務(wù)器作為客戶端和資源所有者的中介來獲取的. 所以這里不是采用直接從資源所有者獲得授權(quán)的方式, 而是采用授權(quán)服務(wù)器作為中介的方式. 在授權(quán)服務(wù)器把資源所有者送回到(重定向)客戶端的時(shí)候帶著這個(gè)臨時(shí)的憑據(jù): authorization code (我暫時(shí)叫它授權(quán)碼吧), 它就代表著資源所有者委托給客戶端應(yīng)用的權(quán)限.
Authorization code在安全方面有一些重要的優(yōu)點(diǎn): 可以對客戶端應(yīng)用進(jìn)行身份認(rèn)證; access token是直接發(fā)送到客戶端應(yīng)用的, 不經(jīng)過資源所有者的瀏覽器, 所以不會(huì)暴露access token給外界, 包括資源所有者.
?
2. Implicit
Implicit, 我叫它隱式授權(quán)吧. 它是Authorization Code的一個(gè)簡化版本, 它針對瀏覽器內(nèi)的客戶端應(yīng)用(例如js, angular的應(yīng)用)進(jìn)行了優(yōu)化. 在implicit流程里, 沒有給客戶端發(fā)送授權(quán)碼(authorization code), 而是直接給它發(fā)送了access token. 之所以叫這種授權(quán)類型implicit, 是因?yàn)榱鞒汤锊]有發(fā)行任何中間憑據(jù).
在implicit流程里發(fā)行access token的時(shí)候, 授權(quán)服務(wù)器并沒有對客戶端應(yīng)用進(jìn)行身份認(rèn)證. 某些情況下, 客戶端的身份可以通過帶著access token重定向回客戶端的URI來驗(yàn)證. acces token可能會(huì)暴露給任何使用該瀏覽器的人或者應(yīng)用.
Implicit授權(quán)確實(shí)可以提高瀏覽器內(nèi)應(yīng)用的響應(yīng)性和效率, 畢竟它減少了來回往返的次數(shù). 但是方便可能會(huì)帶來風(fēng)險(xiǎn), 建議如果可以的話盡量使用Authorization Code, 當(dāng)然這個(gè)需要自己去權(quán)衡.
?
3.?Resource Owner Password Credentials
Resource Owner Password Credentials, 資源所有者密碼憑據(jù). 顧名思義, 可以直接使用密碼憑據(jù)(用戶名和密碼)作為授權(quán)來獲得access token. 只有當(dāng)資源所有者和客戶端之間高度信任的時(shí)候并且其它授權(quán)方式不可用的時(shí)候才可以使用這種授權(quán)方式.
這里資源所有者的憑據(jù)只應(yīng)該用于一次請求并用于交換access token. 這種授權(quán)方式可以讓客戶端免于存儲(chǔ)資源所有者的憑據(jù)(如果以后還需要使用的話), 通過交換一個(gè)長期有效的access token或refresh token都可以達(dá)到這種效果.
?
4. Client Credentials
Client Credentials. 有時(shí)候, 資源或者叫資源服務(wù)器并不屬于某個(gè)最終用戶, 也就是沒有資源所有者對該資源負(fù)責(zé). 但是客戶端應(yīng)用肯定還是要訪問這些資源, 這時(shí)候就只能使用Client Credentials這種授權(quán)方式了.
?
OAuth 2.0 的角色和組件
OAuth2的4個(gè)角色前面已經(jīng)介紹過, 分別是: 資源所有者?Resource Owner, 客戶端?Client, 被保護(hù)資源?Protected Resource, 和 授權(quán)服務(wù)器?Authorization Server.
而OAuth2的組件, 前面也都有提到過, 它們是:?Access Token,?Refresh Token?和?Scope?(范圍).
下面簡單介紹下這幾個(gè)組件.
Access Token:?有時(shí)候只被叫做token, 它是用來訪問被保護(hù)資源的憑據(jù). 它是一個(gè)字符串, 它代表了給客戶頒發(fā)的授權(quán), 也就是委托給客戶的權(quán)限. OAuth2本身并沒有對access token的格式或內(nèi)容進(jìn)行定義. 但是access token里面要描述出資源所有者授予的訪問權(quán)限的范圍和持續(xù)時(shí)間.
Access Token 通常對客戶端應(yīng)用是不透明的, 也就是說客戶端無需去查看access token. 客戶端的任務(wù)就是把它展示給被保護(hù)的資源. 其實(shí)access token在整個(gè)OAuth2系統(tǒng)里對任何角色都是不透明的, 授權(quán)服務(wù)器的任務(wù)只是發(fā)行token, 而被保護(hù)資源的任務(wù)是驗(yàn)證token. 但是它們都必須理解access token的構(gòu)成, 并知道access token代表了什么. 而客戶端對于access token應(yīng)該是完全健忘的.
Scopes:?OAuth2的scope表示被保護(hù)資源那里的一套權(quán)限. 在OAuth2里面, scope用區(qū)分大小寫的字符串表示, 可以用空格作為分隔符來表示多個(gè)scope. 這些字符串由授權(quán)服務(wù)器來定義. 而scope字符串的格式和結(jié)構(gòu)在OAuth2里并沒有定義.
Scope對于限制客戶端應(yīng)用的訪問權(quán)限有很重要的作用. 客戶端應(yīng)用可以請求一些scopes, 而授權(quán)服務(wù)器可以允許資源所有者授權(quán)或者拒絕特定的scopes. Scope還具有疊加性.
Refresh Token:?Refresh Token是用來獲得Access Token的憑據(jù). 和acces token差不多, refresh token也是由授權(quán)服務(wù)器發(fā)行給客戶端應(yīng)用的, 客戶端不知道也不關(guān)心refresh token里面有啥. 但與access token不同的是, refresh token不會(huì)被發(fā)送給被保護(hù)的資源. 客戶端是用refresh token來請求新的access token (尤其是當(dāng)現(xiàn)在的access token過期或者失效時(shí)), 但這個(gè)過程就不需要資源所有者的參與了. Refresh Token是可選的, 授權(quán)服務(wù)器會(huì)酌情發(fā)行refresh token, 如果需要的話, refresh token是在發(fā)行access token一同返回的.
此外refresh token還具備讓客戶端應(yīng)用逐漸降低訪問權(quán)限的能力.
通過refresh token來取得新的access token的流程如下:
另外一張彩色圖:
這張彩圖的中文意思是: 客戶端使用當(dāng)前access token訪問被保護(hù)資源的時(shí)候, access token失效或者過期了, 這是從被保護(hù)資源返回了一個(gè)錯(cuò)誤響應(yīng); 然后客戶端使用refresh token向授權(quán)服務(wù)器請求了一個(gè)新的access token; 得到新的access token后, 客戶端使用新的access token請求被保護(hù)資源, 這時(shí)資源就可以被正常的返回給客戶端了.
?
OAuth 2.0的端點(diǎn)
OAuth2定義了一套端點(diǎn)(Endpoint), 端點(diǎn)就是web服務(wù)器的一個(gè)訪問路徑URI.
OAuth2定義的端點(diǎn)有授權(quán)端點(diǎn),?Token端點(diǎn),?它們都在授權(quán)服務(wù)器上.
OAuth2沒有定義這些端點(diǎn)URI應(yīng)該如何被發(fā)現(xiàn)和文檔的結(jié)構(gòu).
授權(quán)端點(diǎn)(authorization endpoint)是用來和資源所有者交互的, 資源所有者在這里進(jìn)行登錄(身份認(rèn)證), 然后通過該端點(diǎn)可以對客戶端進(jìn)行授權(quán)(authorization grant). 授權(quán)服務(wù)器首先要驗(yàn)證資源所有者的身份, 但是驗(yàn)證的方式并不在OAuth2的協(xié)議范圍內(nèi).
Token端點(diǎn)(token endpoint), 客戶端通過向token端點(diǎn)展示它的授權(quán)(auhtorization grant)或refresh token來獲取access token. 除了implicit之外所有的授權(quán)類型都需要使用該端點(diǎn), 因?yàn)閕mplicit的access token是直接發(fā)行的.
?
本篇文章先到這. 下篇文章再簡單介紹一下OpenId Connect.
那四種授權(quán)類型具體的詳細(xì)流程將在介紹Identity Server 4的時(shí)候一同介紹.
原文地址：https://www.cnblogs.com/cgzl/p/9221488.html
.NET社區(qū)新聞，深度好文，歡迎訪問公眾號(hào)文章匯總 http://www.csharpkit.com
總結(jié)
以上是生活随笔為你收集整理的要用Identity Server 4 -- OAuth 2.0 超级简介的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 在Docker中部署Asp.net co
- 下一篇： 【开源】OSharpNS，轻量级.net