JWT(Json Web Token)观众"aud"与Client_Id - 有什么区别?

Chr*_*ain 89 oauth oauth-2.0 jwt

我正在我的身份验证服务器中实现OAuth 2.0 JWT access_token.但是,我不清楚JWT"aud"声明与client_id http标头值之间的差异.它们是一样的吗?如果没有,你能解释两者之间的区别吗?

我怀疑"aud"应该引用资源服务器,而client_id应该引用认证服务器识别的客户端应用程序之一(即web应用程序或IOS应用程序).

在我目前的情况下,我的资源服务器也是我的Web应用程序客户端.

Chr*_*ain 113

事实证明,我的怀疑是正确的.JWT中的受众"aud"声明旨在引用应接受令牌的资源服务器.

正如这篇文章简单地说的那样:

令牌的受众是令牌的预期接收者.

受众值是一个字符串 - 通常是要访问的资源的基地址,例如" https://contoso.com ".

OAuth中的client_id指的是将从资源服务器请求资源的客户端应用程序.

客户端应用程序(例如您的IOS应用程序)将从您的身份验证服务器请求JWT.在这样做时,它会传递它的client_id和client_secret以及可能需要的任何用户凭据.授权服务器使用client_id和client_secret验证客户端并返回JWT.

JWT将包含一个"aud"声明,指定JWT有效的资源服务器.如果"aud"包含"www.myfunwebapp.com",但客户端应用程序尝试在"www.supersecretwebapp.com"上使用JWT,则访问将被拒绝,因为资源服务器将看到JWT不适用于它.

  • 似乎aud也可能是client_id.请参阅https://tools.ietf.org/id/draft-hunt-oauth-v2-user-a4c-01.txt``audse'require for session_token.包含接收断言.`的客户端的client_id (5认同)
  • @Andy Issuer 指的是授权服务器,audience 指的是资源服务器。有时,它们可以是同一台服务器。但不总是。例如,如果您使用Google帐户登录Web应用程序,则Google会处理授权,您是资源所有者,并且您的资源将由Web应用程序提供服务器。 (4认同)
  • RFC 表示受众 (aud) 标识收件人。收件人会收到您的 JWT 令牌。如果您有一个 Web 应用程序,那么这可能是 https://contoso.com/ 但如果您有一些桌面或移动应用程序(进行身份验证),则受众没有任何 URI。发行者是生成 JWT 令牌的人,因此很可能是服务器的地址。RFC 说这个声明的使用是可选的,所以只在你需要的时候使用它。 (2认同)
  • 事实上,我很困惑观众和发行人之间的区别。 (2认同)

Kek*_*koa 55

JWT aud(受众)索赔

根据RFC 7519:

"aud"(观众)声明标识了JWT的目标收件人.每个打算处理JWT的校长都必须在受众索赔中标明自己的价值.如果处理索赔的委托人在存在此索赔时未在"aud"索赔中标识其自身,那么JWT必须被拒绝.在一般情况下,"aud"值是一个区分大小写的字符串数组,每个字符串包含一个StringOrURI值.在JWT有一个受众的特殊情况下,"aud"值可以是包含StringOrURI值的单个区分大小写的字符串. 对受众价值的解释通常是针对具体应用的. 使用此声明是可选的.

aud规范定义的Audience()声明是通用的,并且是特定于应用程序的.预期用途是识别令牌的预期接收者.收件人的意思是特定于应用程序.受众值可以是字符串列表,也可以是单个字符串(如果只有一个aud声明).令牌的创建者不强制执行aud正确验证,责任是接收者确定是否应该使用令牌.

无论价值是什么,当收件人验证JWT并且它希望验证该令牌是否用于其目的时,它必须确定aud标识自身的值,并且令牌应仅验证收件人的声明ID是否为本中aud,根据权利要求.如果这是URL或其他特定于应用程序的字符串,则无关紧要.例如,如果我的系统决定aud用字符串标识自己:api3.app.com那么它应该只接受JWT,如果aud声明包含api3.app.com在其的受众值列表中.

当然,收件人可能会选择忽略aud,因此这仅在收件人希望肯定验证是否专门为其创建令牌时才有用.

我基于规范的解释是,aud声明对于创建仅针对特定目的有效的专用JWT非常有用.对于一个系统,这可能意味着您希望令牌对某些功能有效,但对其他功能无效.您可以发出仅限于某些"受众"的令牌,同时仍使用相同的密钥和验证算法.

由于在典型情况下,JWT由受信任的服务生成,并由其他受信任的系统(不想使用无效令牌的系统)使用,因此这些系统只需要协调它们将使用的值.

当然,aud完全是可选的,如果您的用例不能保证,可以忽略它.如果您不想限制令牌被特定受众使用,或者您的系统实际上都不会验证aud令牌,那么它就没用了.

示例:访问与刷新令牌

我能想到的一个设计(但简单)的例子可能是我们想要使用JWT来访问和刷新令牌而不必实现单独的加密密钥和算法,而只是想确保访问令牌不会验证为刷新令牌,或者副本-versa.

通过使用,aud我们可以在创建这些令牌时指定refresh刷新令牌的声明和access访问令牌的声明.当请求从刷新令牌获取新的访问令牌时,我们需要验证刷新令牌是否为真正的刷新令牌.在aud上述验证会告诉我们令牌是否实际上是一个有效的刷新令牌被专的要求看refreshaud.

OAuth客户端ID与JWT aud声明

OAuth客户端ID完全不相关,与JWT aud声明没有直接关联.从OAuth的角度来看,令牌是不透明的对象.

接受这些令牌的应用程序负责解析和验证这些令牌的含义.我认为在JWT aud声明中指定OAuth客户端ID没有多大价值.

  • 总的来说,我有点模糊"必须识别自己".RFC7519充满了这样的无法解释的位,以及对其他auth系统的模糊暗示,这可能是对标准声明字段的正确解释.坦率地说,RFC虽然有用,但绝不应该在这样的状态下离开草案阶段. (3认同)
  • 目前,我们对如何使用aud-field进行了相同的讨论,我同意它的意思是包含接收者(验证并接受令牌的人)而不是client_id(请求令牌执行操作的人)代表用户)。 (2认同)

Kav*_*uwa 8

虽然这已经很老了,但我认为这个问题即使在今天仍然有效

我怀疑 aud 应该指资源服务器,而 client_id 应该指身份验证服务器识别的客户端应用程序之一

是的,aud应该指代币消费方。client_id指的token获取方。

在我目前的情况下,我的资源服务器也是我的网络应用程序客户端。

在OP的场景中,Web应用程序和资源服务器都属于同一方。所以这意味着客户和受众是相同的。但在某些情况下,情况可能并非如此。

考虑一下使用 OAuth 受保护资源的 SPA。在这个场景中,SPA 是客户端。受保护的资源是访问令牌的受众。

第二个场景很有趣。RFC8707“ OAuth 2.0 的资源指示器”解释了您可以在哪里使用资源参数定义授权请求中的目标受众。因此,生成的令牌将仅限于指定的受众。此外,Azure OIDC 使用类似的方法,允许资源注册并允许身份验证请求包含资源参数来定义访问令牌的目标受众。这种机制允许 OAuth adpotations 在客户端和令牌消费(受众)方之间进行分离。


Jos*_*h A 8

如果您来这里搜索 OpenID Connect (OIDC):OAuth 2.0 != OIDC

我承认这是为 oauth 2.0 和NOT OIDC 标记的,但是这两个标准之间经常存在混淆,因为这两个标准都可以使用 JWT 和aud声明。一个(OIDC)基本上是另一个(OAUTH 2.0)的扩展。(我自己在寻找 OIDC 时偶然发现了这个问题。)

OAuth 2.0 访问令牌##

对于 OAuth 2.0访问令牌,现有答案很好地涵盖了它。此外,这里是OAuth 2.0 框架 (RFC 6749) 中的一个相关部分

对于使用隐式流的公共客户端,本规范没有为客户端提供任何方法来确定访问令牌颁发给哪个客户端。
...
向客户端验证资源所有者超出了本规范的范围。任何使用授权过程作为委托给客户端的最终用户身份验证形式的规范(例如,第三方登录服务)不得在没有额外安全机制的情况下使用隐式流程,这些安全机制将使客户端能够确定访问令牌是为它的使用而发布的(例如,受众限制访问令牌)。

OIDC ID 代币##

除了访问令牌之外,OIDC 还具有ID 令牌。OIDC 规范明确说明了audID 令牌中声明的使用。( openid-connect-core-1.0 )


需要aud。此 ID 令牌适用的受众。它必须包含依赖方的 OAuth 2.0 client_id 作为受众值。它还可以包含其他受众的标识符。在一般情况下,aud 值是一个区分大小写的字符串数组。在有一个观众的常见特殊情况下,aud 值可能是一个区分大小写的字符串。

此外,OIDC 指定了azpaudwhenaud具有多个值一起使用的声明。

azp
可选。授权方 - 向其颁发 ID 令牌的一方。如果存在,它必须包含此方的 OAuth 2.0 客户端 ID。仅当 ID 令牌具有单一受众值且该受众与授权方不同时才需要此声明。即使授权方与唯一受众相同,它也可以包含在内。azp 值是包含 StringOrURI 值的区分大小写的字符串。

  • 只需注意一件事:Oauth2 不强制使用 JWT。 (2认同)