来自 azure 活动目录的访问令牌的颁发者是 https://sts.windows.net 当我期待 https://login.microsoftonline.com

Question

我正在尝试验证从 azure 活动目录获得的访问令牌。

我从https://login.microsoftonline.com/{{my tennant guid}}/v2.0 获得了令牌

返回的令牌中的发行人是https://sts.windows.net//{{my tennant guid}}/ 不匹配。

如果我检查 at.well-known/openid-configuration 的配置，发行者符合预期https://login.microsoftonline.com/... 。

我在 git 集线器上发现了一个类似的问题https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/560

结果是在 AAD 的应用程序注册中手动编辑清单 json 并设置“accessTokenAcceptedVersion”：2

我已经这样做了，但没有任何区别。

我在这里也看到过关于堆栈溢出的类似问题，但这些问题与租赁 guid 的差异有关——这里不是这种情况。

Answer 1

因此，在清单中将acceptedTokenVersion 更改为2 似乎确实发生了变化，但只是需要时间才能生效。

是的，根据我在 v2 令牌中的测试，观众始终是客户端 ID。

Answer 2

如果您正在验证 api，则在启动类中添加以下代码：

return 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。

Answer 3

发行者 ID 乍一看没问题——它是一个表示 Azure AD 标识的逻辑 URL。

查看 JWT 标头并查看它是否包含 nonce 值。 这些似乎总是无法通过标准访问令牌验证。

如果是这样，那么使用 v1 OAuth 端点可能会修复它 - 尽管可能有替代解决方案。 值得张贴（经过消毒的）JWT 内容的屏幕截图。