JWT(Json Web令牌)受众“ aud”与Client_Id的区别是什么?


103

我正在我的认证服务器中实现OAuth 2.0 JWT access_token。但是,我不清楚JWT aud声明和client_idHTTP标头值之间的区别是什么。他们是一样的吗?如果没有,您能否解释两者之间的区别?

我的怀疑是aud应该引用资源服务器,而client_id应该引用身份验证服务器识别的客户端应用程序之一(即Web应用程序或iOS应用程序)。

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

Answers:


132

事实证明,我的猜想是对的。audJWT中的观众声明是指应接受令牌的资源服务器。

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

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

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

client_id在的OAuth是指将来自资源服务器将请求资源的客户端应用程序。

客户端应用程序(例如您的iOS应用程序)将向您的身份验证服务器请求JWT。这样,它会传递它client_id以及client_secret可能需要的所有用户凭据。授权服务器使用client_id和验证客户端,client_secret并返回JWT。

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


6
似乎aud也可能是client_id。参见tools.ietf.org/id/draft-hunt-oauth-v2-user-a4c-01.txt aud REQUIRED for session_token. Contains the client_id of the client receiving the assertion.
themihai 2015年

1
资源服务器不知道客户端将JWT发送到哪里。资源服务器将如何拒绝从iOS应用到其他URL的此类流量?我不认为你是对的。
John Korsnes '16

我会说“如果“ aud”包含“ www.webapp.com”,但客户端应用程序会尝试在“ secret.webapp.com”上使用JWT”
catamphetamine

2
RFC表示听众(aud)标识了收件人。收件人会收到您的JWT令牌。如果您有一个Web应用程序,则可能是contoso.com,但是如果您有一些台式机或移动应用程序(用于身份验证),则观众没有任何URI。发行者是谁生成的JWT令牌,因此很可能是服务器的地址。RFC表示此声明的使用是可选的,因此仅在需要时使用它。
康拉德

1
实际上,我很困惑受众与发行人之间的区别。
安迪

62

JWT aud(受众群体)索赔

根据RFC 7519

“听众”(观众)声明标识了JWT的目标收件人。每个打算处理JWT的负责人必须在受众声明中标识自己的价值。如果存在该声明时,处理该声明的委托人未使用“ aud”声明中的值标识自身,则必须拒绝JWT。通常,“ aud”值是区分大小写的字符串数组,每个字符串都包含StringOrURI值。在特殊情况下,当JWT有一个听众时,“ aud”值可以是一个包含StringOrURI值的区分大小写的字符串。 受众价值的解释通常是特定于应用程序的。 使用此声明是可选的。

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

无论该值是什么,当接收方正在验证JWT并希望验证令牌是否打算用于其目的时,它都必须确定aud自身的值,并且令牌仅应在接收方声明的ID为存在于aud索赔中。这是URL还是其他特定于应用程序的字符串都没有关系。例如,如果我的系统决定aud使用字符串标识自己:api3.app.com那么,仅当aud声明包含api3.app.com在受众群体值列表中时,它才应接受JWT 。

当然,接收者可能会选择忽略aud,因此仅当接收者想要肯定地验证令牌是专门为其创建的时,这才有用。

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

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

当然,它aud是完全可选的,如果您的用例不保证它可以忽略。如果您不想将令牌限制为仅由特定的受众使用,或者您的系统实际上都不会验证aud令牌,则它是无用的。

示例:访问令牌与刷新令牌

我可以想到的一个人为(但很简单)的示例可能是我们想使用JWT来访问和刷新令牌,而不必实现单独的加密密钥和算法,而只是想确保访问令牌不会作为刷新令牌而有效,否则-反之亦然。

通过使用,aud我们可以在创建这些令牌时指定refresh刷新令牌的声明和access访问令牌的声明。当请求从刷新令牌中获取新的访问令牌时,我们需要验证刷新令牌是真正的刷新令牌。如上所述的aud验证将通过专门查找refreshin 的声明来告诉我们该令牌是否实际上是有效的刷新令牌aud

OAuth客户端ID与JWT aud声明

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

接受这些令牌的应用程序负责解析和验证这些令牌的含义。在JWT aud声明中指定OAuth客户端ID时,我看不到太多价值。


3
我对整个“必须自我识别”有点模糊。RFC7519充满了诸如此类的无法解释的位,以及对其他身份验证系统的含糊暗指,这很可能会在对标准声明字段的正确解释中找到。坦白说,RFC虽然可能有用,但绝不应该处于这种状态。
查克·亚当斯

1
我编辑@ChuckAdams以澄清自己的想法。我同意RFC非常模糊,尤其是围绕“标准声明”以及如何/何时使用它们。
Kekoa,2016年

2
目前,我们就如何使用aud-field进行了相同的讨论,我同意它的意思是包含接收者(验证并接受令牌的人)而不是client_id(请求令牌执行操作的人)代表用户)。
hardysim

4

如果您来这里搜索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
REQUIRED。该ID令牌的目标受众。它必须包含依赖方的OAuth 2.0 client_id作为受众值。它也可以包含其他受众的标识符。通常,aud值是区分大小写的字符串数组。在只有一个听众的特殊情况下,aud值可以是单个区分大小写的字符串。

此外,OIDC指定azpaud何时aud具有多个值一起使用的声明。

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


1
只是要注意一件事:Oauth2不会强制使用JWT。
zoran

1

尽管这很老,但我认为问题甚至在今天仍然有效

我的怀疑是aud应该引用资源服务器,而client_id应该引用身份验证服务器认可的客户端应用程序之一

是的,aud应指代代币使用方。而CLIENT_ID指令牌获取方。

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

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

考虑使用消耗OAuth保护资源的SPA。在这种情况下,SPA是客户端。受保护的资源是访问令牌的受众。

第二种情况很有趣。有一个名为“ OAuth 2.0的资源指标 ”的工作草案,该草案解释了您可以在授权请求中定义目标受众的位置。因此,生成的令牌将仅限于指定的受众。此外,Azure OIDC使用类似的方法,该方法允许资源注册并允许auth请求包含资源参数,以定义访问令牌预期的访问者。这种机制允许OAuth分配在客户端和令牌消费(受众)方之间进行分隔。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.