免責(zé)聲明

如果覺(jué)得我必須從一個(gè)重要的免責(zé)聲明開(kāi)始這篇文章： 不要太相信我要說(shuō)的話。 我之所以這樣說(shuō)，是因?yàn)槲覀冋谟懻摪踩浴?而且， 當(dāng)您談?wù)摪踩詴r(shí)，除了100％正確的陳述外，還有冒任何其他風(fēng)險(xiǎn)的風(fēng)險(xiǎn)。 因此，請(qǐng)記住本文，牢記您的真理來(lái)源應(yīng)為官方規(guī)格 ，這只是我自己腦中概述該主題并將其介紹給初學(xué)者的概述。

任務(wù)

我決定寫(xiě)這篇文章是因?yàn)槲铱偸前l(fā)現(xiàn)OAuth2令人困惑 。 即使現(xiàn)在我對(duì)此有所了解，我還是覺(jué)得有些困惑。
即使當(dāng)我需要擺弄它們的API時(shí)，即使能夠遵循Google或Pinterest之類的在線教程， 也總是感覺(jué)像是一種伏都教 ，帶有所有這些代碼和Bearer令牌。
每當(dāng)他們提到我可以針對(duì)特定步驟做出自己的決定時(shí)（在標(biāo)準(zhǔn)OAuth2方法中進(jìn)行選擇），我的頭腦就會(huì)變得盲目。

希望我能解決一些問(wèn)題，以便從現(xiàn)在開(kāi)始，您可以更加放心地遵循OAuth2教程。

什么是OAuth2？

讓我們從定義開(kāi)始：

OAuth 2是一個(gè)授權(quán) 框架 ，使應(yīng)用程序能夠獲得對(duì)HTTP服務(wù)上用戶帳戶的有限訪問(wèn)權(quán)限 。

上面的句子是可以合理理解的 ，但是如果我們確定所選的術(shù)語(yǔ)，我們可以改進(jìn)。

名稱的Auth部分顯示其本身為Authorization （可能是Authentication；不是）。
框架很容易被忽略，因?yàn)榭蚣芤辉~經(jīng)常被濫用； 但是要保留在這里的想法是， 它不一定是最終產(chǎn)品或完全定義的東西 。 這是一個(gè)工具集。 想法，方法和定義明確的交互作用的集合，您可以使用這些交互作用在其之上構(gòu)建內(nèi)容！
它使應(yīng)用程序能夠獲得有限的訪問(wèn)權(quán)限 。 這里的關(guān)鍵是它使應(yīng)用程序不是人類 。 對(duì)用戶帳戶的有限訪問(wèn)可能是定義的關(guān)鍵部分，它可以幫助您記住和解釋什么是OAuth2： 主要目的是允許用戶委派對(duì)用戶擁有的資源的訪問(wèn)。 將其委托給應(yīng)用程序。

OAuth2與委派有關(guān)。

它是關(guān)于一個(gè)人的，它指示軟件代表她做某事。
該定義還提到了受限訪問(wèn)權(quán)限 ，因此您可以想象能夠僅委派部分功能。
最后總結(jié)到提到HTTP服務(wù) 。 授權(quán)委托發(fā)生在HTTP服務(wù)上 。

OAuth2之前的委派

既然上下文應(yīng)該更加清晰，我們可以自問(wèn)： 在OAuth2和類似概念出現(xiàn)之前，事情是如何完成的？

好吧，在大多數(shù)情況下，情況就像您猜到的一樣糟糕： 有一個(gè)共享的秘密 。

如果我希望授予軟件A訪問(wèn)服務(wù)器B上我的東西的權(quán)限，那么大多數(shù)時(shí)候，方法是將用戶/密碼授予軟件A，以便它可以代表我使用它。 您仍然可以在許多現(xiàn)代軟件中看到這種模式，我個(gè)人希望它會(huì)讓您感到不舒服。 您知道他們?cè)谡f(shuō)什么： 如果您共享一個(gè)秘密，那就不再是秘密！

現(xiàn)在想象一下，如果您可以為需要與之共享某些服務(wù)的每個(gè)服務(wù)創(chuàng)建一個(gè)新的管理員/密碼對(duì)。 我們稱它們為臨時(shí)密碼 。 它們與您用于特定服務(wù)的主帳戶有所不同，但是它們?nèi)匀辉试S訪問(wèn)與您相同的服務(wù)。 在這種情況下，您將可以委派，但您仍將負(fù)責(zé)跟蹤需要?jiǎng)?chuàng)建的所有這些僅適用于應(yīng)用程序的新帳戶。

OAuth2 –想法

請(qǐng)記住，我們要解決的業(yè)務(wù)問(wèn)題是“委托”問(wèn)題，我們希望擴(kuò)展臨時(shí)密碼的概念，以減輕用戶管理這些臨時(shí)密碼的負(fù)擔(dān)。
OAuth2調(diào)用這些臨時(shí)密碼令牌 。
令牌實(shí)際上還不止于此，我將嘗試說(shuō)明它，但是將它們與一個(gè)更簡(jiǎn)單的即席即席密碼概念聯(lián)系起來(lái)可能會(huì)很有用。

OAuth2 –核心業(yè)務(wù)

Oauth 2核心業(yè)務(wù)涉及：

• 如何獲得代幣

OAuth2 –什么是令牌？

既然一切似乎都圍繞令牌，那么什么是令牌？
到目前為止，我們已經(jīng)使用了即席密碼的類比，這種密碼對(duì)我們很有用，但也許我們可以做得更好。
如果我們?cè)贠Auth2規(guī)范中尋找答案怎么辦？ 好吧，準(zhǔn)備失望。 OAuth2規(guī)范未提供有關(guān)如何定義令牌的詳細(xì)信息。 為什么甚至有可能呢？ 還記得我們說(shuō)過(guò)OAuth2只是“一個(gè)框架”嗎？ 好吧，這是定義很重要的情況之一！ 規(guī)范只是告訴您令牌是什么的邏輯定義，并描述了令牌需要具備的某些功能。 但最后，規(guī)范說(shuō)的是令牌是字符串。 包含訪問(wèn)資源的憑據(jù)的字符串。 它提供了更多細(xì)節(jié)，但是可以說(shuō)在大多數(shù)情況下，令牌中的內(nèi)容并不重要。 只要應(yīng)用程序能夠使用它們。

令牌就是那種東西，它允許應(yīng)用程序訪問(wèn)您感興趣的資源。

為了指出如何避免過(guò)分思考令牌是什么，規(guī)范還明確指出“對(duì)客戶端通常是不透明的”！ 它們實(shí)際上是在告訴您甚至不需要您了解它們！ 要記住的事情更少，聽(tīng)起來(lái)不錯(cuò)！

但是為了避免將其變成純粹的哲學(xué)課，讓我們展示一下令牌可能是什么

{"access_token": "363tghjkiu6trfghjuytkyen","token_type": "Bearer" }

快速瀏覽一下，可以告訴我們，這是一個(gè)字符串。 類似于JSON，但這可能只是因?yàn)閖son最近很流行，而不一定是必需的。 我們可以發(fā)現(xiàn)一個(gè)部分，看起來(lái)像一個(gè)隨機(jī)字符串，一個(gè)id： 363tghjkiu6trfghjuytkyen 。 程序員知道，當(dāng)您看到類似這樣的內(nèi)容時(shí)，至少在字符串不太長(zhǎng)的時(shí)候，這可能表明它只是一個(gè)密鑰，您可以將其與存儲(chǔ)在其他位置的更詳細(xì)的信息相關(guān)聯(lián)。 在這種情況下也是如此。 更具體地說(shuō)，附加信息將是有關(guān)該代碼所代表的特定授權(quán)的詳細(xì)信息。

但是，另一件事應(yīng)該引起您的注意： "token_type": "Bearer" 。

您的合理問(wèn)題應(yīng)該是： Bearer令牌類型的特征是什么？ 還有其他類型嗎？ 哪個(gè)？

幸運(yùn)的是，由于我們努力使事情變得簡(jiǎn)單，答案很簡(jiǎn)單（有人可能會(huì)說(shuō)，很容易造成混淆……）

規(guī)格僅談?wù)揃earer令牌類型！

嗯，為什么這樣設(shè)計(jì)令牌的人覺(jué)得他必須指定唯一的已知值？ 您可能會(huì)在這里開(kāi)始看到一種模式：因?yàn)镺Auth2只是一個(gè)框架！
它建議您如何做事，并為您做出選擇提供一些繁重的工作，但最后，您有責(zé)任使用框架來(lái)構(gòu)建所需的內(nèi)容。
我們只是說(shuō)，盡管在這里我們只討論Bearer令牌，但這并不意味著您不能定義自定義類型，而是允許您將其歸因于它。

好的，只是一種類型。 但這是一個(gè)奇怪的名字 。 名稱是否暗示任何相關(guān)內(nèi)容？ 也許這是一個(gè)愚蠢的問(wèn)題，但是對(duì)于像我這樣的非英語(yǔ)母語(yǔ)人士來(lái)說(shuō)， Bearer在這種情況下的含義可能會(huì)有些混亂。

實(shí)際上，其含義很簡(jiǎn)單：

不記名令牌是指如果您有有效的令牌，我們就會(huì)信任您。 無(wú)話可問(wèn)。

如此簡(jiǎn)單，令人困惑。 您可能會(huì)爭(zhēng)辯：“好吧，現(xiàn)實(shí)世界中所有類似令牌的對(duì)象都是這樣工作的：如果我有有效的錢(qián)，則將它們換成出售的商品”。

正確。 這是無(wú)記名令牌的有效示例。

但是，并非每個(gè)令牌都屬于Bearer。 例如，機(jī)票不是持票人代幣。 僅憑一張機(jī)票就不能登機(jī)了 。 您還需要顯示一個(gè)有效的ID，以便您的票證可以與之匹配； 如果您的姓名與機(jī)票相符，而您的面部與身份證相符，則可以登機(jī)。

總結(jié)一下，我們正在使用一種令牌，如果您擁有其中的一個(gè)，就足以訪問(wèn)資源。

并且請(qǐng)您思考：我們說(shuō)過(guò)OAuth2與授權(quán)有關(guān)。 如果您希望將令牌傳遞給某人進(jìn)行委派，則具有此特征的令牌顯然很方便。

令牌類比

再一次，這可能是我的非英語(yǔ)母語(yǔ)背景，建議我進(jìn)行澄清。 當(dāng)我尋找意大利語(yǔ)的第一筆代幣翻譯時(shí)，我指的是一個(gè)物理對(duì)象。 像這樣：

具體來(lái)說(shuō)，這是一個(gè)古老的令牌，用于在公用電話亭撥打電話。 盡管是Bearer令牌，但與OAuth2令牌的類比卻很差。
蒂姆·布雷（Tim Bray）在此舊帖子中設(shè)計(jì)了一張更好的圖片： 旅館鑰匙是訪問(wèn)令牌我建議您直接閱讀文章，但主要思想是，與我首先鏈接的實(shí)物金屬硬幣相比，則您的軟件令牌可以使用一段時(shí)間，可以遠(yuǎn)程禁用并可以攜帶信息。

參與的演員

這些是我們的演員：

• 資源所有者
• 客戶端（又名應(yīng)用程序）
• 授權(quán)服務(wù)器
• 受保護(hù)的資源

應(yīng)該相對(duì)直觀： 應(yīng)用程序要訪問(wèn)資源所有者擁有的受保護(hù)資源 。 為此，它需要一個(gè)令牌。 令牌由Authorization Server發(fā)出， Authorization Server是所有其他參與者都信任的第三方實(shí)體。

通常，當(dāng)閱讀新內(nèi)容時(shí)，我傾向于快速跳過(guò)系統(tǒng)參與者。 也許我不應(yīng)該，但是在大多數(shù)情況下，討論的段落描述了一個(gè)“用戶”，但最終使用很多單詞來(lái)告訴我這只是一個(gè)很好的用戶……所以我嘗試尋找不太直觀的術(shù)語(yǔ)，并檢查其中一些是否具有我應(yīng)該特別注意的特征。

在OAuth2特定情況下，我覺(jué)得名稱最混亂的演員是Client 。
我為什么這么說(shuō)呢？ 因?yàn)樵谡Ｉ钪?#xff08;和IT中），它可能意味著許多不同的事物：用戶，專用軟件，非常通用的軟件……

我更喜歡將其歸類為Application 。

強(qiáng)調(diào)客戶端是我們要向其委派權(quán)限的應(yīng)用程序。 因此，例如，如果該應(yīng)用程序是我們通過(guò)瀏覽器訪問(wèn)的服務(wù)器端Web應(yīng)用程序， 則客戶端不是用戶，也不是瀏覽器本身：客戶端是在自己的環(huán)境中運(yùn)行的Web應(yīng)用程序。

我認(rèn)為這很重要。 客戶術(shù)語(yǔ)無(wú)處不在，所以我的建議不是完全替換它，而是要讓您的大腦牢記客戶=應(yīng)用程序的關(guān)系。

我還想認(rèn)為還有另一個(gè)非官方的Actor：用戶代理。

我希望我不會(huì)在這里使人們感到困惑，因?yàn)檫@完全是我用來(lái)構(gòu)建思維導(dǎo)圖的東西。
盡管沒(méi)有在規(guī)范中進(jìn)行定義，也沒(méi)有出現(xiàn)在所有不同的流中，但它可以幫助您識(shí)別OAuth2流中的第五個(gè)Actor。
用戶代理在大多數(shù)情況下都是由Web瀏覽器模擬的。 它的職責(zé)是在兩個(gè)彼此不直接交談的系統(tǒng)之間實(shí)現(xiàn)信息的間接傳播。 這個(gè)想法是：A應(yīng)該與B對(duì)話，但不允許這樣做。 因此，A告訴C（用戶代理）告訴B某些事情。

目前可能還有些混亂，但是我希望以后能澄清一下。

OAuth2核心業(yè)務(wù)2

OAuth2關(guān)于如何獲取令牌。

即使您不是OAuth2的專家，只要有人提到該主題，您可能會(huì)立即想到來(lái)自Google或其他主要服務(wù)提供商的頁(yè)面，這些頁(yè)面在您嘗試登錄您所不依賴的新服務(wù)時(shí)會(huì)彈出還沒(méi)有帳戶，然后告訴Google，是的，您信任該服務(wù)，并且希望將對(duì)Google的部分權(quán)限委派給該服務(wù)。

這是正確的，但這只是OAuth2定義的多種可能的交互之一 。

有四個(gè)主要方面，您知道這一點(diǎn)很重要。 如果這是您第一次聽(tīng)到，可能會(huì)感到驚訝：
并非所有人都會(huì)最終向您顯示類似Google的權(quán)限屏幕！
這是因?yàn)槟踔量赡芟Ｍㄟ^(guò)命令行工具來(lái)利用OAuth2方法。 甚至根本沒(méi)有任何用戶界面，能夠?yàn)槟@示一個(gè)交互式網(wǎng)頁(yè)以委派權(quán)限。

再次記住：主要目標(biāo)是獲得代幣！

如果您找到一種獲取方式的方法，并且能夠使用它們，那么您就完成了。

正如我們所說(shuō)的，OAuth2框架定義了4種方式。 有時(shí)將它們稱為流程，有時(shí)將其稱為Grants 。
你怎么稱呼它們并不重要。 我個(gè)人使用流程，因?yàn)樗梢詭椭姨嵝涯?#xff0c;在與不同參與者進(jìn)行交互以獲取令牌時(shí)，它們彼此不同。

他們是：

• 授權(quán)碼流程
• 隱式撥款流
• 客戶憑證授予流程
• 資源所有者憑證授予流（又名密碼流）

其中每一個(gè)都是針對(duì)特定方案的建議流程。
為了給您提供一個(gè)直觀的示例，在某些情況下，您的客戶端可以保守秘密（服務(wù)器端Web應(yīng)用程序），而在其他情況下技術(shù)上則無(wú)法（對(duì)于客戶端網(wǎng)絡(luò)應(yīng)用程序，您可以使用瀏覽器完全檢查其代碼） 。
像剛剛描述的那樣，環(huán)境約束將使整個(gè)流程中定義的某些步驟變得不安全（且無(wú)用）。 因此，為了簡(jiǎn)化起見(jiàn)，在完全跳過(guò)了一些不可能的交互或未添加任何安全性相關(guān)值的交互時(shí)，定義了其他流程。

OAuth2 Poster Boy：授權(quán)代碼流

我們將從以下三個(gè)原因開(kāi)始討論授權(quán)代碼流：

• 這是最著名的流程，您可能已經(jīng)與之交互過(guò)（這是類似Google的委托屏幕）
• 這是最復(fù)雜，明確和固有的安全性
• 與之相比，其他流程更容易推論

如果客戶是受信任的并且能夠保密，則應(yīng)使用“授權(quán)代碼流”。 這意味著服務(wù)器端Web應(yīng)用程序。

如何使用授權(quán)碼流程獲取令牌

所有參與的參與者都信任授權(quán)服務(wù)器

用戶（資源所有者）告訴客戶（應(yīng)用程序）代表他做某事

客戶端將用戶重定向到授權(quán)服務(wù)器，并添加一些參數(shù)： redirect_uri ， response_type=code ， scope ， client_id

授權(quán)服務(wù)器詢問(wèn)用戶是否希望代表客戶（授權(quán)）授予客戶端訪問(wèn)特定資源（范圍）的某些資源。

用戶接受委托請(qǐng)求，因此Auth Server現(xiàn)在向User-Agent（瀏覽器）發(fā)送一條指令，以重定向到客戶端的url。 還將code=xxxxx注入此HTTP重定向指令中。

通過(guò)HTTP重定向已由User-Agent激活的客戶端現(xiàn)在直接與授權(quán)服務(wù)器對(duì)話（繞過(guò)User-Agent）。 client_id ， client_secret和code （已轉(zhuǎn)發(fā)）。

授權(quán)服務(wù)器返回客戶端（不是瀏覽器）有效的access_token和refresh_token

它是如此清晰，以至于也被稱為OAuth2舞蹈！

讓我們強(qiáng)調(diào)以下幾點(diǎn)：

• 在第2步中，我們?cè)谄渌麉?shù)中指定了redirect_uri 。 當(dāng)我們將User-Agent作為參與者之一引入時(shí)，這用于實(shí)現(xiàn)我們預(yù)期的間接通信。 如果我們要允許授權(quán)服務(wù)器在不打開(kāi)兩者之間的直接網(wǎng)絡(luò)連接的情況下將信息轉(zhuǎn)發(fā)給客戶端，則這是關(guān)鍵信息。
• 第2步中提到的scope是客戶端要求的一組權(quán)限
• 請(qǐng)記住，這是在客戶端完全受保護(hù)時(shí)使用的流程。 當(dāng)客戶端與授權(quán)服務(wù)器之間的通信避免通過(guò)安全性較低的User-Agent（可能會(huì)嗅探或篡改通信）時(shí)，這與步驟5的流程有關(guān)。 這也是為什么有意義的是，客戶端可以啟用更高的安全性，即發(fā)送僅在客戶端和授權(quán)服務(wù)器之間共享的client_secret 。
• refresh_token用于客戶端可能需要對(duì)授權(quán)服務(wù)器執(zhí)行的后續(xù)自動(dòng)調(diào)用。 當(dāng)前的access_token到期并且需要獲取新的access_token時(shí)，發(fā)送有效的refresh_token可以避免再次要求用戶確認(rèn)委派。

OAuth2獲得了令牌，現(xiàn)在呢？

OAuth2是一個(gè)記住框架。 該框架告訴我現(xiàn)在要做什么？

好吧，什么都沒(méi)有。 = P

這取決于客戶開(kāi)發(fā)人員。

她可以（通常應(yīng)該）：

• 檢查令牌是否仍然有效
• 查找有關(guān)誰(shuí)授權(quán)此令牌的詳細(xì)信息
• 查找與該令牌相關(guān)的權(quán)限是什么
• 最終允許訪問(wèn)資源的任何其他有意義的操作

它們都是有效的，而且很明顯，對(duì)嗎？ 開(kāi)發(fā)人員是否必須自己找出最佳的操作集才能下一步執(zhí)行？ 她絕對(duì)可以。 否則，她可以利用另一個(gè)規(guī)范：OpenIDConnect（OIDC）。 稍后再詳細(xì)介紹。

OAuth2 –隱式授權(quán)流程

這是為客戶端應(yīng)用程序設(shè)計(jì)的流程，不能保密 。 客戶端HTML應(yīng)用程序就是一個(gè)明顯的例子。 但是，即使是任何公開(kāi)代碼的二進(jìn)制應(yīng)用程序，也可以被操縱來(lái)提取其秘密。
我們不能重新使用授權(quán)碼流程嗎？ 是的，但是...如果秘密不再是安全的秘密，步驟5）的意義何在？ 從這個(gè)額外的步驟中我們將得不到任何保護(hù)！
因此，隱式授予流與授權(quán)碼流相似，但是它不會(huì)執(zhí)行無(wú)用的步驟5。 它旨在直接獲得access_tokens，而無(wú)需先獲取密碼的中間步驟，該代碼將與機(jī)密一起交換以獲得access_token。

它使用response_type=token來(lái)具體說(shuō)明在與授權(quán)服務(wù)器聯(lián)系時(shí)要使用的流。 而且也沒(méi)有refresh_token 。 這是因?yàn)榧僭O(shè)用戶會(huì)話很短（由于安全性較差的環(huán)境），并且無(wú)論如何，用戶仍將重新確認(rèn)他的委托意愿（這是導(dǎo)致定義的主要用例）的refresh_tokens ）。

OAuth2 –客戶憑證授予流程

如果我們沒(méi)有資源所有者，或者他與客戶端軟件本身不明確（1：1關(guān)系）怎么辦？
想象一個(gè)僅想與另一個(gè)后端系統(tǒng)對(duì)話的后端系統(tǒng)。 沒(méi)有用戶參與。 這種交互的主要特征是，它不再是交互性的，因?yàn)槲覀儾辉傩枰魏斡脩魜?lái)確認(rèn)他要委派某些東西的意愿。 它還隱式定義了一個(gè)更安全的環(huán)境，您不必?fù)?dān)心主動(dòng)用戶冒著讀取機(jī)密的風(fēng)險(xiǎn)。

其類型為response_type=client_credentials 。

我們不會(huì)在這里詳述它，只是要知道它的存在，并且就像前面的流程一樣，它是完整OAuth舞蹈的一種變體，實(shí)際上是一種簡(jiǎn)化，如果您的情況允許，建議您使用它。

OAuth2 –資源所有者憑證授予流（又名密碼流）

請(qǐng)?jiān)谶@里引起您的注意，因?yàn)槟鷮⒏械嚼Щ蟆?/strong>

這是這種情況：資源所有者在授權(quán)服務(wù)器上擁有一個(gè)帳戶。 資源所有者將其帳戶詳細(xì)信息提供給客戶。 客戶端使用此詳細(xì)信息向授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證…

= O

如果您已經(jīng)進(jìn)行了討論，那么您可能會(huì)問(wèn)我是否在開(kāi)玩笑。 這正是我們?cè)贠Auth2探索之初試圖擺脫的反模式！

如何找到此處列出的建議流程？

答案實(shí)際上是相當(dāng)合理的： 這是從舊版系統(tǒng)遷移的第一步 。 它實(shí)際上比共享密碼反模式好一點(diǎn)：
密碼是共享的，但這只是啟動(dòng)用于獲取令牌的OAuth Dance的一種手段。

如果我們沒(méi)有更好的選擇，這可以讓OAuth2站起來(lái)。 它引入了access_tokens的概念，直到體系結(jié)構(gòu)足夠成熟（或環(huán)境將發(fā)生變化）以允許更好和更安全的Flow獲取令牌之前，都可以使用它。 另外，請(qǐng)注意，現(xiàn)在令牌是到達(dá)受保護(hù)資源系統(tǒng)的臨時(shí)密碼，而在完全共享的密碼反模式中，這是我們需要轉(zhuǎn)發(fā)的密碼。

因此，這遠(yuǎn)非理想，但至少我們通過(guò)一些標(biāo)準(zhǔn)證明了這一點(diǎn)。

如何選擇最佳流量？

互聯(lián)網(wǎng)上有很多決策流程圖。 我最喜歡的一個(gè)是這個(gè)：

來(lái)自https://auth0.com

它應(yīng)該可以幫助您記住我在這里給您的簡(jiǎn)短描述，并根據(jù)您的環(huán)境選擇最簡(jiǎn)單的流程。

OAuth2返回令牌– JWT

因此，我們現(xiàn)在可以獲取令牌。 我們有多種獲取途徑。 我們沒(méi)有明確告訴我們?nèi)绾翁幚硭鼈?#xff0c;但是通過(guò)一些額外的工作和對(duì)授權(quán)服務(wù)器的大量調(diào)用，我們可以安排一些事情并獲得有用的信息。

情況會(huì)更好嗎？

例如，我們假設(shè)票價(jià)如此之高，以致我們的代幣可能看起來(lái)像這樣：

{"access_token": "363tghjkiu6trfghjuytkyen","token_type": "Bearer" }

我們可以在其中包含更多信息，以便為我們節(jié)省前往授權(quán)服務(wù)器的往返時(shí)間嗎？

如下所示會(huì)更好：

{"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",... : ... }

我們將能夠直接訪問(wèn)一些與資源所有者委托相關(guān)的信息。

幸運(yùn)的是，其他人也有相同的想法，他們提出了JWT – JSON Web令牌 。
JWT是定義代表一組聲明的基于JSON的令牌的結(jié)構(gòu)的標(biāo)準(zhǔn)。 正是我們想要的！

實(shí)際上，JWT規(guī)范提供給我們的最重要方面不是我們上面示例的有效負(fù)載，而是在不涉及Authorizatin Server的情況下信任整個(gè)令牌的能力！

這怎么可能呢？ 這個(gè)想法不是一個(gè)新想法： JOSE specs在JWT的上下文中定義的非對(duì)稱簽名（pubkey）。

讓我為您刷新一下：

在非對(duì)稱簽名中，使用兩個(gè)密鑰來(lái)驗(yàn)證信息的有效性。
這兩個(gè)密鑰是耦合的，但是一個(gè)是秘密的，只有文檔創(chuàng)建者才知道，而另一個(gè)是公開(kāi)的。
秘密用于計(jì)算文檔的指紋； 哈希。 當(dāng)文檔發(fā)送到目的地時(shí)，讀取器使用與秘密密鑰關(guān)聯(lián)的公共密鑰來(lái)驗(yàn)證文檔和他收到的指紋是否有效。 數(shù)字簽名算法告訴我們，只有通過(guò)相應(yīng)的秘密密鑰對(duì)文檔進(jìn)行簽名后，該文檔才是有效的。

總體思路是：如果我們的本地驗(yàn)證通過(guò)了，我們可以確保消息已由密鑰所有者發(fā)布，因此它是隱式可信的。

回到我們的令牌用例：

我們收到令牌。 我們可以信任此令牌嗎？ 我們?cè)?strong>本地驗(yàn)證令牌，而無(wú)需聯(lián)系發(fā)行人。 當(dāng)且僅當(dāng)基于可信公鑰的驗(yàn)證通過(guò)時(shí)，我們確認(rèn)令牌有效。 沒(méi)問(wèn)題。 如果令牌根據(jù)數(shù)字標(biāo)牌是有效的，并且根據(jù)聲明的壽命有效，那么我們可以將這些信息視為真實(shí)信息，而無(wú)需向授權(quán)服務(wù)器請(qǐng)求確認(rèn)！

可以想象，由于我們將所有信任都放在令牌中，因此不發(fā)出壽命過(guò)長(zhǎng)的令牌可能是明智的：
某人可能已在授權(quán)服務(wù)器上更改了他的委派首選項(xiàng)，并且該信息可能尚未到達(dá)客戶端，該客戶端仍然具有可以基于其決定進(jìn)行有效簽名的令牌。
最好使事情保持更多同步，發(fā)出壽命較短的令牌，因此，最終過(guò)時(shí)的偏好不會(huì)長(zhǎng)期受到信任。

OpenID連接

我希望本節(jié)不會(huì)令您失望，但是本文已經(jīng)篇幅冗長(zhǎng)且內(nèi)容豐富，因此，我特意使它簡(jiǎn)短。

OAuth2 + JWT + JOSE?= OpenID Connect

再一次：OAuth2是一個(gè)框架。
OAuth2框架與JWT規(guī)范，JOSE和我們將在此處不詳述的其他想法（創(chuàng)建OpenID Connect規(guī)范）結(jié)合使用。

您應(yīng)該帶回的想法是，您可能更經(jīng)常對(duì)使用和利用OpenID Connect感興趣，因?yàn)樗鼌R集了此處定義的最佳方法和想法。
是的，您是在利用OAuth2，但是現(xiàn)在您是OpenID Connect的定義更為明確的界限，它為您提供了更豐富的令牌和對(duì)Authentication的支持，而普通的OAuth2從未涵蓋過(guò)。

一些在線服務(wù)可讓您在OAuth2或OpenID Connect之間進(jìn)行選擇。 這是為什么？
好吧，當(dāng)他們提到OpenID Connect時(shí)，您知道您正在使用標(biāo)準(zhǔn)。 即使您切換實(shí)現(xiàn)，也會(huì)有相同的行為。
給出的OAuth2選項(xiàng)可能非常相似，可能具有您可能感興趣的一些殺手級(jí)功能，但在更通用的OAuth2框架之上進(jìn)行了自定義。 因此，請(qǐng)謹(jǐn)慎選擇。

結(jié)論

如果您對(duì)此主題感興趣，或者如果本文僅讓您更困惑，建議您查看Justin Richer和Antonio Sanso的OAuth 2 in Action 。
另一方面，如果您想檢查您的新鮮知識(shí)并將其應(yīng)用于開(kāi)放源代碼授權(quán)服務(wù)器，我絕對(duì)會(huì)建議您使用Keycloak ，它具有我們?cè)诖嗣枋龅乃泄δ?#xff0c;并且還有更多！

翻譯自: https://www.javacodegeeks.com/2017/06/oauth2-jwt-open-id-connect-confusing-things.html

總結(jié)

以上是生活随笔為你收集整理的OAuth2，JWT，Open-ID Connect和其他令人困惑的事物的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。