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

Posted 2023-03-27

【中文标题】当我期待 https://login.microsoftonline.com 时，来自天蓝色活动目录的访问令牌中的颁发者是 https://sts.windows.net

【英文标题】：Issuer in access token from azure active directory is https://sts.windows.net when I'm expecting https://login.microsoftonline.com

【发布时间】：2020-05-04 12:14:34

【问题描述】：

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

我从https://login.microsoftonline.com/mytennant guid/v2.0 获得令牌

返回的令牌中的颁发者是https://sts.windows.net//mytennant 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

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

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

【问题讨论】：

您为 API 编辑了应用注册清单，对吗？那应该将令牌更改为 v2..

是的，我更改了客户端和 api 的清单

你能展示你用来获取令牌的代码吗？

我刚刚准备了一个示例令牌以使用 jwt.io 发布，该令牌现在包含预期的颁发者。例如login.microsoftonline.com。奇怪的是，观众已经从 api://myapi 变成了我的 clientId Guid。自发布问题以来，我没有更改任何代码，所以我只能假设设置 "accessTokenAcceptedVersion": 2 确实有效，但需要几个小时才能生效。

如果想通过 Graph SDK 以编程方式设置这个，希望这个答案能帮助***.com/a/69341905/2933389

【参考方案1】：

看来将清单中的acceptedTokenVersion更改为2确实发生了变化，但只是需要时间才能生效。

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

【讨论】：

此更改需要多长时间才能生效？我在 30 多分钟前进行了更改，但仍然从 v2 端点返回 v1 令牌。

所以您更改了您请求令牌的 API 的接受令牌版本？

是的，我在令牌请求中使用的应用注册（“客户端”）清单中设置了"accessTokenAcceptedVersion": 2。我正在使用grant_type: password，以防万一。

@BobMeyers 您使用的scope 是什么？我问的原因是在请求令牌的应用程序上设置该属性值很重要，而不是客户端应用程序（除非应用程序当然为自己请求令牌）。

有没有办法以编程方式设置"accessTokenAcceptedVersion": 2，而不是手动更新清单？

【参考方案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。

【参考方案3】：

颁发者 ID 乍一看还不错 - 它是一个表示 Azure AD 身份的逻辑 url。

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

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