身份服務器4如何實現Json Web令牌

Question

我對oauth2令牌和json網絡令牌之間的區別感到非常困惑。 我搜索了這些技術，結果是：

Open Id是一種協議，它使用JSON Web令牌來確保請求來自受信任的用戶。

Json Web令牌包含一些用sts私鑰加密的用戶信息（聲明）。

Oauth2是一個框架，我們可以管理用戶，客戶端和資源以及第三方應用程序之間的登錄操作。

Identity Framework 4是一個開放式ID連接實現.net MVC庫。 該庫使用oauth2規范編寫，並實現了Open Id。

這是我不明白的問題。 Oauth2框架已經具有其令牌實現。

在這種情況下，JSON Web令牌的位置在哪里？ 例如，我們有一個簡單的Web應用程序和一個實現身份服務器4的服務器。

當用戶從Web應用程序請求頁面時，用戶將被重定向到我們的身份服務器以進行登錄操作。 成功登錄后，身份服務器將向我們的響應中添加一個cookie，並且這些cookie中包含一個令牌。 當請求其他安全資源時，我們將使用該令牌。

這些步驟對我來說很清楚。 此schenio中的Jason Web令牌在哪里？ 如何在客戶端應用程序中使用JSON Web令牌？ 我在哪里可以找到我的用戶要求？

Answer 1

在OAuth2的規范中給出了JWT的原因

由於OAuth 2.0並未為資源服務器定義協議來學習有關從服務器接收到的令牌的元信息，因此
授權服務器，已經采用了幾種不同的方法
開發來彌合這種差距。 這些包括使用結構化令牌
格式，例如JWT [RFC7519]或專有的服務間
通訊機制（例如共享數據庫和受保護的
企業服務總線）傳達令牌信息。

作為一種開放標准，JWT已在與安全相關的技術和協議中廣泛采用。 它定義了一種緊湊且自包含的方式，用於在各方之間作為JSON對象安全地傳輸信息。 此信息可以進行驗證和信任，因為它是經過數字簽名的

讓我們進一步解釋該定義的一些概念。

• 緊湊 ：由於尺寸較小，可以通過URL，POST參數或HTTP標頭發送JWT。 此外，較小的尺寸意味着傳輸速度很快。

• 自包含的 ：有效負載包含有關用戶的所有必需信息，從而避免了多次查詢數據庫的需求。

有很多網站解釋這些問題，並且有許多技術提供商。

• https://jwt.io/introduction/提供教程和免費電子書
• https://oauth.net/2/了解更多內容
• https://openid.net/connect/為街上的新孩子

回答與IdentityServer有關的問題。 認證和授權相關信息通常經過編碼

• 訪問令牌
• 身份令牌

這些令牌中的特定於應用程序的信息/有效負載使用JWT進行編碼。 如果提供了良好的庫，那么JWT對應用程序開發人員幾乎是透明的-與IdentityServer一樣。 您可以在出色的IdentityServer文檔中找到問題的答案。 還介紹了如何提取用戶聲明。 該項目提供了許多客戶端示例 ，其中涵蓋了典型的AuthX設置。 它需要時間和精力來克服。

Answer 2

JSON Web令牌 （JWT）（ RFC 7519 ）本身獨立於OAuth 2.0和OpenID Connect。 您可以在任何喜歡的地方使用JWT。

OAuth 2.0是有關如何請求和頒發訪問令牌的規范。 該規范沒有說明應如何表示訪問令牌。 因此，訪問令牌可以是隨機字符串，也可以是JWT。 一些授權服務器實現生成隨機字符串並將其作為訪問令牌頒發，而其他實現生成JWT並將其作為訪問令牌頒發。 參見“ 7。 “ OToken和OpenID Connect的完全實現者談發現 ”中的“ 訪問令牌”進行進一步討論。

OpenID Connect是有關如何請求和發行ID令牌的規范。 規范說ID令牌是一種JWT。 另外，JWT在規范中的其他地方使用。 來自UserInfo Endpoint的響應是純JSON或JWT。 請求對象是JWT。

在正常情況下， 支持OpenID Connect的服務器可以發布ID令牌（為JWT）和訪問令牌（為隨機字符串或JWT） 。 這可能會讓您感到困惑。 閱讀以下文章可能會有所幫助。

1. 所有OpenID Connect流圖
2. 所有OAuth 2.0流程的圖表和電影