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