当前位置: 首页 > 知识库问答 >
问题:

JWT(Json Web令牌)受众“aud”与Client\u Id-有什么区别?

禄奇希
2023-03-14

我正在身份验证服务器中实现OAuth 2.0 JWT access\u令牌。但是,我不清楚JWT aud声明和客户端id HTTP头值之间的区别。它们是一样的吗?如果没有,你能解释一下两者的区别吗?

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

在我当前的案例中,我的资源服务器也是我的Web应用程序客户端。

共有3个答案

澹台志诚
2023-03-14

我知道这是为oauth 2.0而不是OIDC标记的,但是这两个标准之间经常会有混淆,因为这两个标准都可以使用JWTs和aud声明。其中一个(OIDC)基本上是另一个(OAUTH 2.0)的扩展。(我自己在寻找OIDC时偶然发现了这个问题。)

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

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

除了Access令牌之外,OIDC还有ID令牌。OIDC规范明确说明了在ID Tokens中使用aud声明。(openid-conttion-core-1.0)

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

此外,当aud具有多个值时,OIDC指定与aud结合使用的azp声明。

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

秦学林
2023-03-14

根据RFC 7519:

“aud”(受众)声明标识JWT的目标接收者。每个打算处理JWT的主体都必须使用受众声明中的值来标识自己。如果当存在该声明时,处理该声明的主体没有使用“aud”声明中的值来标识自己,则JWT必须被拒绝。在一般情况下,“aud”值是区分大小写的字符串数组,每个字符串都包含一个StringOrURI值。在JWT有一个受众的特殊情况下,“aud”值可以是包含StringOrURI值的单个区分大小写的字符串。受众值的解释通常是特定于应用程序的。此声明的使用是可选的。

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

无论值是什么,当收件人验证JWT并希望验证令牌是否用于其目的时,必须确定aud中的哪个值标识自己,并且只有当收件人声明的ID存在于aud声明中时,令牌才应验证。这是URL还是其他特定于应用程序的字符串并不重要。例如,如果我的系统决定用字符串api3在aud中标识自己。应用程序。com,则仅当aud声明包含api3时,才应接受JWT。应用程序。com在其受众价值列表中。

当然,收件人可以选择忽略aud,因此这仅在收件人希望积极验证令牌是专门为其创建的时才有用。

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

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

当然,aud是完全可选的,如果您的用例不支持,可以忽略它。如果您不想限制令牌被特定受众使用,或者您的任何系统实际上都不会验证aud令牌,那么它是无用的。

我能想到的一个人为的(但简单的)例子是,我们可能希望使用JWT来访问和刷新令牌,而无需实现单独的加密密钥和算法,但只是希望确保访问令牌不会作为刷新令牌进行验证,反之亦然。

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

OAuth Client ID完全不相关,与JWTaud声明没有直接相关性。从OAuth的角度来看,令牌是不透明的对象。

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

郝原
2023-03-14

事实证明,我的怀疑是对的。JWT中的受众aud声明是指应该接受令牌的资源服务器。

正如这篇文章所说:

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

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

OAuth中的客户机id是指将从资源服务器请求资源的客户机应用程序。

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

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

 类似资料:
  • 在我当前的情况下,我的资源服务器也是我的web应用程序客户端。

  • 我想从Stormpath帖子中对JWT令牌和CSRF提出疑问,这些令牌和CSRF解释了将JWT存储在localStorage或Cookie中的优缺点。 [...] 如果您使用JS从cookie中读取值,这意味着您不能在cookie上设置Httponly标志,因此现在站点上的任何JS都可以读取它,从而使其与在localStorage中存储内容的安全级别完全相同。 我试图理解为什么他们建议将xsrfT

  • 现在我有了我的应用程序将嵌入另一个CRM平台的用法。假设这个CRM平台使用IDP1。因此,用户能够访问CRM,并将通过IDP1进行身份验证。然后,用户可以点击一个按钮,并被引导到我的应用程序。当然,我们不希望用户再次使用相同的IdP进行身份验证,但现在首先通过KeyCloak进行身份验证。 我的问题是,有没有一种方法让Keycloak使用用户访问CRM平台时收到的IDP1令牌,让Keycloak充

  • 我正在使用这个库node jwks rsa从auth0 jwks获取JWT密钥。json文件,以验证我的应用程序在身份验证后检索的id_令牌实际上来自我的身份验证提供程序。 在引擎盖下,它使用此方法构建公钥PEM (使用x50c作为. jwks文件中的参数)。 然后,我将其与jsonwebToken结合使用,以验证JWT(id_token)是否有效。 这种验证方法与根据jwks的模和指数生成私钥(

  • 我使用OWIN/Katana OAuth 2.0授权服务器创建了AuthorizationServer。它被配置为使用JWT作为AccessTokenFormat。这里的签名凭证来自每个受众独有的受众秘密。 我想构建一个客户端,该客户端使用这个AuthorizationServer获取令牌,用于使用我构建的两个API(资源/受众)。 我看到在OAuth中没有受众的概念(JWT概念),唯一与此最接近

  • 我们正在使用JWT Nuget来创建和验证令牌。下面是我们用来创建令牌的代码 我的理解是,这不会加密令牌,因为我能够通过访问jwt.io解析令牌,并且能够读取内容。我想加密令牌,这样它就不应该被解析。我在JWT Nuget中找不到任何可以加密令牌的方法。 那么如何使用JWT nuget对令牌进行签名和加密呢? 编辑: 我知道JWT不需要任何加密,因为只有经过身份验证的用户才能读取令牌,这意味着,我