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)樵谡Ｉ钪?#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)槟踔量赡芟Ｍㄟ^命令行工具來利用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)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 捕组词 捕的组词
- 下一篇： 夕怎么组词 夕如何组词