来自Azure AD的访问令牌颁发者是sts.windows.net而不是login.microsoftonline.com

zlwx9yxi  于 12个月前  发布在  Windows
关注(0)|答案(3)|浏览(111)

我正在尝试验证从azure active directory获取的访问令牌。
我从https://login.microsoftonline.com/{{my tennant guid}}/v2.0获得令牌
返回的令牌中的发行者是https://sts.windows.net//{{my tennant guid}}/,这不匹配。
如果我在.well-known/openid-configuration检查配置,则颁发者如预期的那样为https://login.microsoftonline.com/....
我在git hub上发现了类似的问题https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/560
建议是在AAD中的应用程序注册中手动编辑清单的json并设置"accessTokenAcceptedVersion": 2
我已经做了,但它没有任何区别。为什么?为什么?

vbkedwbf

vbkedwbf1#

因此,在清单中将acceptedTokenVersion更改为2似乎确实发生了变化,但需要时间才能生效。
是的,观众总是基于我在v2令牌中的测试的客户端ID。

relj7zay

relj7zay2#

如果您正在验证一个API,则在启动类中添加以下代码:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
        .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
   {
      options.Authority  = "https://login.microsoftonline.com/<TenantId>/v2.0";
      options.Audience   = "<Audience>";
      options.TokenValidationParameters.ValidIssuer 
                         = "https://sts.windows.net/<TenantId>/";
   });

上面的代码,通知正确的Issuer

svmlkihl

svmlkihl3#

acceptedTokenVersion改为2的公认答案是正确的。然而,还有一点细微差别:

  • 它可能需要一段时间才能生效的原因是你的客户端库,比如JavaScript的MSAL,可以缓存令牌,并将在一段时间内继续提供版本1令牌。我怀疑这就是为什么公认的答案和评论都在谈论它是如何花了几个小时才生效的。
  • 如果你使用msal-browser for node.js并按照这里的说明来提高性能,你需要特别注意你使用2.0版本的端点来填充authorityMetadata。在写这篇文章的时候,说明书是不完整的,而且有误导性,很容易犯这个错误。

相关问题