B2C：使用客户凭证与授权流程时，受众声明的格式不同

Question

我得到相同的值，但格式不同

aud

在使用相同的客户端ID和使用B2C用户流请求的范围时使用

client_credential

和

authorization_code

授予类型时我的JWT声明。

交互式验证码流程

POST /tenant.onmicrosoft.com/B2C_1_app_SignIn/oauth2/v2.0/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: PostmanRuntime/7.36.1
Accept: */*
Cache-Control: no-cache
Postman-Token: e392d8bc-8766-4d7b-bac5-32a5716a8600
Host: tenant.b2clogin.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 1120
 
grant_type=authorization_code&code=<code>&redirect_uri=https%3A%2F%2Foauth.pstmn.io%2Fv1%2Fcallback&code_verifier=<verifier>&client_id=<clientid>

回应：

{"access_token":"<jwt>","token_type":"Bearer",
"not_before":1706064107,"expires_in":3600,
"expires_on":1706067707,"resource":"<resource>","profile_info":"<profile>",
"scope":"https://tenant.onmicrosoft.com/177da752-d895-4325-9aee-d6e459bee811/app.full_access",
"refresh_token":"<refresh token>","refresh_token_expires_in":86400}

解码后的 JWT 值：

"aud": "177da752-d895-4325-8aee-d6e459bee811"

非交互式客户端凭证流程

POST /tenant.onmicrosoft.com/b2c_1_app_signin/oauth2/v2.0/token HTTP/1.1
User-Agent: PostmanRuntime/7.36.1
Accept: */*
Host: tenant.b2clogin.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 231
 
client_id=<clientid>&scope=https%3A%2F%2Ftenant.onmicrosoft.com%2F177da752-d895-4325-9aee-d6e459bee811%2F.default&client_secret=<secret>&grant_type=client_credentials

回复：

{"access_token":"<jwt>","token_type":"Bearer","not_before":1706057659,"expires_in":3600,"expires_on":1706061259,"resource":"https://tenant.onmicrosoft.com/177da752-d895-4325-9aee-d6e459bee811"}

解码后的 JWT 值

"aud": "https://tenant.onmicrosoft.com/177da752-d895-4325-8aee-d6e459bee811"

这是设计使然吗？

提前致谢。

Answer 1

是的。

客户端凭据具有应用程序的上下文，而代码授予具有用户的上下文。

Answer 2

您提供的示例中的

aud

和

sub

JWT 声明之间似乎存在一些混淆。

在您的情况下，由于您使用相同的客户端 ID 并且（假设）您在授权代码和客户端凭证流中针对相同的资源，因此您会期望两个令牌中的

aud

声明是相同的。您看到的不同值是不寻常的。这可能是由于一些配置错误或令牌端点的实现方式造成的，也许需要向提供商询问澄清？请记住，

aud

声明是关于代币的去向，而不是谁正在使用它。 “谁”部分由

sub

声明表示。这在 RFC 7519 中进行了解释。

所以，长话短说：如果客户端要访问“api.my-domain.com”，那么这应该始终是 JWT 中的

aud

值，无论它是通过交互式身份验证代码还是通过非交互式客户端凭证流程。