oauth2和jwt_OAuth2,JWT,Open-ID Connect和其他令人困惑的事物
oauth2和jwt
免責(zé)聲明
如果覺得我必須從一個重要的免責(zé)聲明開始這篇文章: 不要太相信我要說的話。 我之所以這樣說,是因?yàn)槲覀冋谟懻摪踩浴?而且, 當(dāng)您談?wù)摪踩詴r,除了100%正確的陳述外,還有冒任何其他風(fēng)險的風(fēng)險。 因此,請記住本文,牢記您的真理來源應(yīng)為官方規(guī)格 ,這只是我自己腦中概述該主題并將其介紹給初學(xué)者的概述。
任務(wù)
我決定寫這篇文章是因?yàn)槲铱偸前l(fā)現(xiàn)OAuth2令人困惑 。 即使現(xiàn)在我對此有所了解,我還是覺得有些困惑。
即使當(dāng)我需要擺弄它們的API時,即使能夠遵循Google或Pinterest之類的在線教程, 也總是感覺像是一種伏都教 ,帶有所有這些代碼和Bearer令牌。
每當(dāng)他們提到我可以針對特定步驟做出自己的決定時(在標(biāo)準(zhǔn)OAuth2方法中進(jìn)行選擇),我的頭腦就會變得盲目。
希望我能解決一些問題,以便從現(xiàn)在開始,您可以更加放心地閱讀OAuth2教程。
什么是OAuth2?
讓我們從定義開始:
OAuth 2是一個授權(quán) 框架 ,使應(yīng)用程序能夠獲得對HTTP服務(wù)上用戶帳戶的有限訪問權(quán)限 。
上面的句子是可以合理理解的 ,但是如果我們確定所選的術(shù)語,我們可以改進(jìn)。
名稱的Auth部分顯示其本身為Authorization (可能是Authentication;不是)。
框架很容易被忽略,因?yàn)榭蚣芤辉~經(jīng)常被濫用; 但是要保留在這里的想法是, 它不一定是最終產(chǎn)品或完全定義的東西 。 這是一個工具集。 想法,方法和定義明確的交互作用的集合,您可以使用這些交互作用在其之上構(gòu)建內(nèi)容!
它使應(yīng)用程序能夠獲得有限的訪問權(quán)限 。 這里的關(guān)鍵是它使應(yīng)用程序不是人類 。 對用戶帳戶的有限訪問可能是定義的關(guān)鍵部分,它可以幫助您記住和解釋什么是OAuth2: 主要目的是允許用戶委派對用戶擁有的資源的訪問。 將其委托給應(yīng)用程序。
OAuth2與委派有關(guān)。
它是關(guān)于一個人的,指示軟件代表她做某事。
該定義還提到了受限訪問權(quán)限 ,因此您可以想象能夠僅委派部分功能。
最后總結(jié)到提到HTTP服務(wù) 。 授權(quán)委托發(fā)生在HTTP服務(wù)上 。
OAuth2之前的委派
現(xiàn)在,上下文應(yīng)該更加清晰了,我們可以問問自己: 在OAuth2和類似概念問世之前,事情是如何完成的?
好吧,在大多數(shù)情況下,這就像您猜中的那樣糟糕: 擁有一個共享的秘密 。
如果我希望授予軟件A訪問服務(wù)器B上我的東西的權(quán)限,則大多數(shù)時候,該方法是將用戶/密碼授予軟件A,以便它可以代表我使用它。 您仍然可以在許多現(xiàn)代軟件中看到這種模式,我個人希望它會讓您感到不舒服。 您知道他們在說什么: 如果您共享一個秘密,那就不再是秘密!
現(xiàn)在想象一下,如果您可以為需要與之共享某些服務(wù)的每個服務(wù)創(chuàng)建一個新的管理員/密碼對。 我們稱它們為臨時密碼 。 它們與您用于特定服務(wù)的主帳戶有所不同,但它們?nèi)栽试S訪問與您相同的服務(wù)。 在這種情況下,您將可以委派,但您仍將負(fù)責(zé)跟蹤需要創(chuàng)建的所有這些僅適用于應(yīng)用程序的新帳戶。
OAuth2 –想法
請記住,我們要解決的業(yè)務(wù)問題是“委托”問題,我們希望擴(kuò)展臨時密碼的概念,以減輕用戶管理這些臨時密碼的負(fù)擔(dān)。
OAuth2調(diào)用這些臨時密碼令牌 。
令牌實(shí)際上還不止于此,我將嘗試說明它,但是將它們與這種更簡單的即席專用密碼概念聯(lián)系起來可能會很有用。
OAuth2 –核心業(yè)務(wù)
Oauth 2核心業(yè)務(wù)是關(guān)于:
- 如何獲得代幣
OAuth2 –什么是令牌?
既然一切似乎都圍繞令牌,那么什么是令牌?
到目前為止,我們已經(jīng)使用了臨時密碼的類比,這種密碼對我們來說很有效,但是也許我們可以做得更好。
如果我們在OAuth2規(guī)范中尋找答案怎么辦? 好吧,準(zhǔn)備失望。 OAuth2規(guī)范未提供有關(guān)如何定義令牌的詳細(xì)信息。 為什么甚至有可能呢? 還記得我們說OAuth2只是“一個框架”嗎? 好吧,這是定義很重要的情況之一! 規(guī)范只是告訴您令牌是什么的邏輯定義,并描述了令牌需要具備的某些功能。 但最后,規(guī)范說的是令牌是字符串。 包含訪問資源的憑據(jù)的字符串。 它提供了更多細(xì)節(jié),但是可以說,在大多數(shù)情況下,令牌中的內(nèi)容并不重要。 只要應(yīng)用程序能夠使用它們。
令牌就是那種東西,它允許應(yīng)用程序訪問您感興趣的資源。
為了指出如何避免過分思考令牌是什么,規(guī)范還明確指出“對客戶端通常是不透明的”! 它們實(shí)際上是在告訴您甚至不需要您了解它們! 要記住的事情更少,聽起來不錯!
但是為了避免將其變成純粹的哲學(xué)課,讓我們展示一下令牌可能是什么
{"access_token": "363tghjkiu6trfghjuytkyen","token_type": "Bearer" }快速瀏覽一下,可以告訴我們,這是一個字符串。 類似于JSON,但這可能只是因?yàn)閖son最近很流行,但不一定是必需的。 我們可以發(fā)現(xiàn)一個部分,看起來像一個隨機(jī)字符串,一個id: 363tghjkiu6trfghjuytkyen 。 程序員知道,當(dāng)您看到類似這樣的內(nèi)容時,至少在字符串不太長的時候,這可能表明它只是一個密鑰,您可以將其與存儲在其他位置的更詳細(xì)的信息相關(guān)聯(lián)。 在這種情況下也是如此。 更具體地說,附加信息將是有關(guān)該代碼所代表的特定授權(quán)的詳細(xì)信息。
但是,另一件事應(yīng)該引起您的注意: "token_type": "Bearer" 。
您的合理問題應(yīng)該是: Bearer令牌類型的特征是什么? 還有其他類型嗎? 哪個?
幸運(yùn)的是,由于我們努力使事情變得簡單,答案很簡單(有人可能會說,很容易造成混淆……)
規(guī)格僅談?wù)揃earer令牌類型!
嗯,為什么以這種方式設(shè)計(jì)令牌的人覺得他必須指定唯一的已知值? 您可能會在這里開始看到一種模式:因?yàn)镺Auth2只是一個框架!
它建議您如何做事,并且為您做出選擇提供了一些繁重的工作,但是最后,您有責(zé)任使用框架來構(gòu)建所需的內(nèi)容。
我們只是說,盡管在這里我們僅討論Bearer令牌,但這并不意味著您無法定義自定義類型,而是允許您將其歸因于它。
好的,只是一種類型。 但這是一個奇怪的名字 。 名稱是否暗示任何相關(guān)內(nèi)容? 也許這是一個愚蠢的問題,但是對于像我這樣的非英語母語人士來說,在這種情況下, Bearer意思可能會有些混亂。
實(shí)際上,其含義很簡單:
不記名令牌是指如果您擁有有效的令牌,我們就會信任您。 無話可問。
如此簡單,令人困惑。 您可能會爭辯:“好吧,現(xiàn)實(shí)世界中所有類似令牌的對象都以這種方式工作:如果我有有效的錢,就將它們換成出售的商品”。
正確。 這是無記名令牌的有效示例。
但是,并非每個令牌都屬于Bearer。 例如,機(jī)票不是持票人代幣。 僅憑一張機(jī)票就不能登機(jī)了 。 您還需要顯示一個有效的ID,以便您的票證可以與之匹配; 如果您的姓名與機(jī)票相符,而您的面部與身份證相符,則可以登機(jī)。
總結(jié)一下,我們正在使用一種令牌,如果您擁有其中一個令牌,則足以訪問資源。
并且請您思考:我們說過OAuth2與授權(quán)有關(guān)。 如果您要將令牌傳遞給某人進(jìn)行委派,則具有此特征的令牌顯然很方便。
令牌類比
再次,這可能是我的非英語母語背景,建議我進(jìn)行澄清。 當(dāng)我尋找意大利語的第一筆令牌翻譯時,我指的是一個物理對象。 像這樣:
具體來說,這是一個古老的令牌,用于在公用電話亭撥打電話。 盡管是Bearer令牌,但它與OAuth2令牌的類比非常差。
蒂姆·布雷(Tim Bray)在此舊帖子中設(shè)計(jì)了一張更好的圖片: 酒店鑰匙是訪問令牌我建議您直接閱讀文章,但主要思想是,與我首先鏈接的實(shí)體金屬硬幣相比,則您的軟件令牌可以使用一段時間,可以遠(yuǎn)程禁用并可以攜帶信息。
參與的演員
這些是我們的演員:
- 資源所有者
- 客戶端(又名應(yīng)用程序)
- 授權(quán)服務(wù)器
- 受保護(hù)的資源
應(yīng)該相對直觀: 應(yīng)用程序要訪問資源所有者擁有的受保護(hù)資源 。 為此,它需要一個令牌。 令牌由Authorization Server發(fā)出, Authorization Server是所有其他參與者都信任的第三方實(shí)體。
通常,當(dāng)閱讀新內(nèi)容時,我傾向于快速跳過系統(tǒng)的參與者。 也許我不應(yīng)該,但是在大多數(shù)情況下,談?wù)摰亩温涿枋隽艘粋€“用戶”,但最終使用很多單詞來告訴我這只是一個很好的用戶……所以我嘗試尋找不太直觀的術(shù)語,并檢查其中一些是否具有我應(yīng)該特別注意的特征。
在OAuth2特定情況下,我覺得名稱最混亂的演員是Client 。
我為什么這么說呢? 因?yàn)樵谡I钪?#xff08;和IT中),它可能意味著許多不同的事物:用戶,專用軟件,非常通用的軟件……
我更喜歡將其歸類為Application 。
強(qiáng)調(diào)客戶端是我們要向其委派權(quán)限的應(yīng)用程序。 因此,例如,如果該應(yīng)用程序是我們通過瀏覽器訪問的服務(wù)器端Web應(yīng)用程序, 則客戶端不是用戶,也不是瀏覽器本身:客戶端是在其自身環(huán)境中運(yùn)行的Web應(yīng)用程序。
我認(rèn)為這很重要。 客戶術(shù)語無處不在,所以我的建議不是完全替換它,而是要讓您的大腦牢記客戶=應(yīng)用程序的關(guān)系。
我也想認(rèn)為還有另一個非官方的Actor:User-Agent。
我希望我不會在這里使人們感到困惑,因?yàn)檫@完全是我用來構(gòu)建思維導(dǎo)圖的東西。
盡管沒有在規(guī)范中進(jìn)行定義,并且也沒有出現(xiàn)在所有不同的流中,但它可以幫助識別OAuth2流中的第五個Actor。
用戶代理在大多數(shù)情況下都是由Web瀏覽器模擬的。 它的職責(zé)是在兩個彼此不直接交談的系統(tǒng)之間間接傳播信息。 這個想法是:A應(yīng)該與B對話,但不允許這樣做。 因此,A告訴C(用戶代理)告訴B某些事情。
目前可能還有些混亂,但是我希望以后可以澄清這一點(diǎn)。
OAuth2核心業(yè)務(wù)2
OAuth2關(guān)于如何獲取令牌。
即使您不是OAuth2的專家,只要有人提到該主題,您可能會立即想到來自Google或其他主要服務(wù)提供商的頁面,這些頁面在您嘗試登錄您所不依賴的新服務(wù)時會彈出還沒有帳戶,然后告訴Google,是的,您信任該服務(wù),并且希望將對Google的部分權(quán)限委派給該服務(wù)。
這是正確的,但這只是OAuth2定義的多種可能的交互之一 。
重要的有四個,您知道這一點(diǎn)很重要。 如果這是您第一次聽到,可能會感到驚訝:
并非所有人都會最終向您顯示類似Google的權(quán)限屏幕!
這是因?yàn)槟踔量赡芟Mㄟ^命令行工具來利用OAuth2方法。 甚至根本沒有任何用戶界面,它能夠顯示一個交互式網(wǎng)頁來委派權(quán)限。
再次記住:主要目標(biāo)是獲得代幣!
如果您找到一種獲取方式的方法,并且能夠使用它們,那么您就完成了。
正如我們所說的,OAuth2框架定義了4種方式。 有時將它們稱為流程,有時將其稱為Grants 。
你怎么稱呼它們并不重要。 我個人使用流程,因?yàn)樗兄谖姨嵝涯?#xff0c;在與不同參與者進(jìn)行交互以獲取令牌時,它們彼此不同。
他們是:
- 授權(quán)碼流程
- 隱式撥款流
- 客戶憑證授予流程
- 資源所有者憑證授予流(又名密碼流)
它們中的每一個都是針對特定方案的建議流程。
為了給您提供一個直觀的示例,在某些情況下,您的客戶端可以保守秘密(服務(wù)器端Web應(yīng)用程序),而在其他情況下技術(shù)上則無法(在客戶端Web應(yīng)用程序中您可以使用瀏覽器完全檢查其代碼) 。
像剛剛描述的環(huán)境約束一樣,環(huán)境約束將使整個流程中定義的某些步驟變得不安全(且無用)。 因此,為簡化起見,當(dāng)完全跳過了一些不可能或未添加任何安全性相關(guān)值的交互時,已定義了其他流程。
OAuth2海報男孩:授權(quán)代碼流
由于以下三個原因,我們將從授權(quán)代碼流開始討論:
- 這是最著名的流程,您可能已經(jīng)與之交互過(這是類似Google的委托屏幕)
- 這是最復(fù)雜,明確和固有的安全性
- 與之相比,其他流程更容易推理
如果客戶是受信任的并且能夠保密,則應(yīng)使用“授權(quán)代碼流”。 這意味著服務(wù)器端Web應(yīng)用程序。
如何使用授權(quán)碼流程獲取令牌
它是如此清晰,以至于也被稱為OAuth2舞蹈!
讓我們強(qiáng)調(diào)以下幾點(diǎn):
- 在第2步中,我們在其他參數(shù)中指定了redirect_uri 。 當(dāng)我們將User-Agent作為參與者之一引入時,這用于實(shí)現(xiàn)我們預(yù)期的間接通信。 這是關(guān)鍵信息,如果我們要允許授權(quán)服務(wù)器在不打開兩者之間的直接網(wǎng)絡(luò)連接的情況下將信息轉(zhuǎn)發(fā)給客戶端。
- 步驟2中提到的scope是客戶端要求的一組權(quán)限
- 請記住,這是在客戶端完全受保護(hù)時使用的流程。 當(dāng)客戶端與授權(quán)服務(wù)器之間的通信避免通過安全性較低的User-Agent(可能會嗅探或篡改通信)時,這與步驟5的流程有關(guān)。 這也是為什么有意義的是,客戶端可以啟用更高的安全性,即發(fā)送僅在客戶端和授權(quán)服務(wù)器之間共享的client_secret 。
- refresh_token用于客戶端可能需要對授權(quán)服務(wù)器執(zhí)行的后續(xù)自動調(diào)用。 當(dāng)前的access_token到期并且需要獲取一個新的access_token時,發(fā)送有效的refresh_token可以避免再次要求用戶確認(rèn)委派。
OAuth2獲得了令牌,現(xiàn)在呢?
OAuth2是一個記住框架。 該框架告訴我現(xiàn)在要做什么?
好吧,什么都沒有。 = P
由客戶開發(fā)人員決定。
她可以(通常應(yīng)該):
- 檢查令牌是否仍然有效
- 查找有關(guān)誰授權(quán)此令牌的詳細(xì)信息
- 查找與該令牌相關(guān)的權(quán)限是什么
- 最終允許訪問資源的任何其他有意義的操作
它們都是有效的,而且很明顯,對嗎? 開發(fā)人員是否必須自己找出最佳的操作集才能下一步執(zhí)行? 她絕對可以。 否則,她可以利用另一個規(guī)范:OpenIDConnect(OIDC)。 稍后再詳細(xì)介紹。
OAuth2 –隱式授權(quán)流程
這是為客戶端應(yīng)用程序設(shè)計(jì)的流程,不能保密 。 客戶端HTML應(yīng)用程序就是一個明顯的例子。 但是,即使是任何公開代碼的二進(jìn)制應(yīng)用程序,也可以被操縱來提取其秘密。
我們不能重新使用授權(quán)碼流程嗎? 是的,但是……如果秘密不再是安全的秘密,那么步驟5)的意義何在? 從這個額外的步驟中我們將得不到任何保護(hù)!
因此,隱式授予流與授權(quán)碼流相似,但是它不會執(zhí)行無用的步驟5。 它旨在直接獲得access_tokens,而無需先獲取密碼的中間步驟,該代碼將與機(jī)密一起交換以獲得access_token。
它使用response_type=token來具體說明在與授權(quán)服務(wù)器聯(lián)系時要使用的流。 而且也沒有refresh_token 。 這是因?yàn)榧僭O(shè)用戶會話很短(由于安全性較差的環(huán)境),并且無論如何,用戶仍將重新確認(rèn)他的委托意愿(這是導(dǎo)致定義的主要用例)的refresh_tokens )。
OAuth2 –客戶憑證授予流程
如果我們沒有資源所有者,或者他與客戶端軟件本身不明確(1:1關(guān)系)怎么辦?
想象一下一個后端系統(tǒng),它只想與另一個后端系統(tǒng)對話。 沒有用戶參與。 這種交互的主要特征是它不再是交互性的,因?yàn)槲覀儾辉傩枰魏斡脩魜泶_認(rèn)他要委派某些東西的意愿。 它還隱式定義了一個更安全的環(huán)境,您不必?fù)?dān)心主動用戶冒著讀取機(jī)密的風(fēng)險。
其類型為response_type=client_credentials 。
我們不會在這里詳述它,只是要知道它的存在,并且就像前面的流程一樣,它是完整OAuth舞蹈的一種變體,實(shí)際上是一種簡化,如果您的情況允許,建議您使用它。
OAuth2 –資源所有者憑證授予流(又名密碼流)
請?jiān)谶@里引起您的注意,因?yàn)槟鷮⒏械嚼Щ蟆?/strong>
這是這種情況:資源所有者在授權(quán)服務(wù)器上擁有一個帳戶。 資源所有者將其帳戶詳細(xì)信息提供給客戶。 客戶端使用此詳細(xì)信息對授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證…
= O
如果您已經(jīng)進(jìn)行了討論,那么您可能會問我是否在開玩笑。 這正是我們在OAuth2探索之初試圖擺脫的反模式!
如何找到此處列出的建議流程?
答案實(shí)際上是相當(dāng)合理的: 這是從舊版系統(tǒng)遷移的第一步 。 它實(shí)際上比共享密碼反模式好一點(diǎn):
密碼是共享的,但這只是啟動用于獲取令牌的OAuth Dance的一種手段。
如果我們沒有更好的選擇,這可以讓OAuth2站起來。 它引入了access_tokens的概念,并且可以使用它直到架構(gòu)足夠成熟(或者環(huán)境將發(fā)生變化)以允許更好和更安全的Flow獲取令牌。 另外,請注意,現(xiàn)在令牌是到達(dá)受保護(hù)資源系統(tǒng)的臨時密碼,而在完全共享的密碼反模式中,這是我們需要轉(zhuǎn)發(fā)的密碼。
因此,這遠(yuǎn)非理想,但至少我們通過一些標(biāo)準(zhǔn)證明了這一點(diǎn)。
如何選擇最佳流量?
互聯(lián)網(wǎng)上有很多決策流程圖。 我最喜歡的一個是這個:
來自https://auth0.com
它應(yīng)該可以幫助您記住我在這里給您的簡短描述,并根據(jù)您的環(huán)境選擇最簡單的流程。
OAuth2返回令牌– JWT
因此,我們現(xiàn)在可以獲取令牌。 我們有多種獲取途徑。 我們沒有明確告訴我們?nèi)绾问褂盟鼈?#xff0c;但是通過一些額外的工作和對授權(quán)服務(wù)器的大量調(diào)用,我們可以安排一些事情并獲得有用的信息。
情況會更好嗎?
例如,我們假設(shè)票價如此之高,以致我們的代幣可能看起來像這樣:
{"access_token": "363tghjkiu6trfghjuytkyen","token_type": "Bearer" }我們能否在其中包含更多信息,以便為我們節(jié)省一些到授權(quán)服務(wù)器的往返路程?
如下所示會更好:
{"active": true,"scope": "scope1 scope2 scope3","client_id": "my-client-1","username": "paolo","iss": "http://keycloak:8080/","exp": 1440538996,"roles" : ["admin", "people_manager"],"favourite_color": "maroon",... : ... }我們將能夠直接訪問與資源所有者委托相關(guān)的一些信息。
幸運(yùn)的是,其他人也有相同的想法,他們提出了JWT – JSON Web令牌 。
JWT是定義代表一組聲明的基于JSON的令牌的結(jié)構(gòu)的標(biāo)準(zhǔn)。 正是我們想要的!
實(shí)際上,JWT規(guī)范給我們的最重要方面不是我們上面舉例說明的有效負(fù)載,而是在不涉及Authorizatin Server的情況下信任整個令牌的能力!
這怎么可能呢? 這個想法不是一個新想法: JOSE specs在JWT的上下文中定義的非對稱簽名(pubkey)。
讓我為您刷新一下:
在非對稱簽名中,使用兩個密鑰來驗(yàn)證信息的有效性。
這兩個密鑰是耦合的,但是一個是秘密的,只有文檔創(chuàng)建者才知道,而另一個是公開的。
秘密用于計(jì)算文件的指紋。 哈希。 當(dāng)文檔發(fā)送到目的地時,讀取器使用與秘密密鑰相關(guān)聯(lián)的公鑰來驗(yàn)證文檔和他收到的指紋是否有效。 數(shù)字簽名算法告訴我們,只有通過相應(yīng)的秘密密鑰對文檔進(jìn)行簽名后,該文檔才是有效的。
總體思路是:如果我們的本地驗(yàn)證通過了,我們可以確保消息已由密鑰所有者發(fā)布,因此它是隱式可信的。
回到我們的令牌用例:
我們收到令牌。 我們可以信任此令牌嗎? 我們在本地驗(yàn)證令牌,而無需聯(lián)系發(fā)行人。 當(dāng)且僅當(dāng)基于可信公鑰的驗(yàn)證通過時,我們確認(rèn)令牌有效。 沒問題。 如果令牌根據(jù)數(shù)字標(biāo)牌是有效的,并且根據(jù)聲明的壽命有效,則可以將這些信息視為真實(shí)信息,而無需向授權(quán)服務(wù)器要求確認(rèn)!
可以想象,由于我們將所有信任都放在令牌中,因此不發(fā)出壽命過長的令牌可能是明智的:
某人可能已在授權(quán)服務(wù)器上更改了他的委派首選項(xiàng),并且該信息可能尚未到達(dá)客戶端,該客戶端仍然具有可以根據(jù)其決定進(jìn)行有效簽名的令牌。
最好使事情保持更多同步,發(fā)出壽命較短的令牌,因此,最終過時的偏好不會長期受到信任。
OpenID連接
我希望本節(jié)不會令您失望,但是本文已經(jīng)篇幅長且內(nèi)容豐富,因此,我特意使它簡短。
OAuth2 + JWT + JOSE?= OpenID Connect
再一次:OAuth2是一個框架。
OAuth2框架與JWT規(guī)范,JOSE以及我們將在此處不詳述的其他想法(創(chuàng)建OpenID Connect規(guī)范)結(jié)合使用。
您應(yīng)該帶回的想法是,您可能更經(jīng)常對使用和利用OpenID Connect感興趣,因?yàn)樗鼌R集了此處定義的最佳方法和想法。
是的,您是在利用OAuth2,但是現(xiàn)在您是OpenID Connect的定義更加明確的界限,它為您提供了更豐富的令牌和對Authentication的支持,而普通的OAuth2從未涵蓋過。
一些在線服務(wù)可讓您在OAuth2或OpenID Connect之間進(jìn)行選擇。 這是為什么?
好吧,當(dāng)他們提到OpenID Connect時,您知道您正在使用標(biāo)準(zhǔn)。 即使您切換實(shí)現(xiàn),也會有相同的行為。
給出的OAuth2選項(xiàng)可能非常相似,可能具有您可能感興趣的一些殺手級功能,但在更通用的OAuth2框架之上進(jìn)行了自定義。 因此,請謹(jǐn)慎選擇。
結(jié)論
如果您對此主題感興趣,或者如果本文僅使您更困惑,建議您查看Justin Richer和Antonio Sanso的OAuth 2 in Action 。
另一方面,如果您想檢查您的新鮮知識并想將其應(yīng)用于開放源代碼授權(quán)服務(wù)器,我絕對會建議您使用Keycloak ,它具有我們在此描述的所有功能,并且還有更多!
翻譯自: https://www.javacodegeeks.com/2017/06/oauth2-jwt-open-id-connect-confusing-things.html
oauth2和jwt
總結(jié)
以上是生活随笔為你收集整理的oauth2和jwt_OAuth2,JWT,Open-ID Connect和其他令人困惑的事物的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 捕组词 捕的组词
- 下一篇: 夕怎么组词 夕如何组词