【发布时间】：2021-06-02 05:03:03
【问题描述】：
我们有许多服务可供用户通过基于 HTTP 的协议 (SOAP/REST/WebDAV) 调用。这些服务支持各种身份验证机制（例如 Basic 和 OIDC Bearer 令牌）。有时，一个服务必须在没有实时用户的情况下调用另一个服务。为此，我们配置技术用户，服务 A 可以使用技术用户的凭据调用 B。
对于通过不记名令牌进行的 OAuth/OIDC 身份验证，我们使用 JWT 不记名令牌流为我们的技术用户获取访问令牌：服务 A 使用技术用户的名称创建一个 JWT，并使用自己的私钥对其进行签名。然后，它使用该令牌调用 OIDC 令牌端点并接收其技术用户 X 的访问令牌。然后，它可以将此令牌用作承载令牌来调用服务 B，该服务 B 将接受用户 X 的令牌。（有关更多信息JWT 承载流，参见 RFC 7523 第 2.1 节和 RFC 7521 第 4 节）。
这适用于我们的 Connect2id 测试服务器和 Salesforce，但我们无法让它与 Azure 一起使用。访问 Azure 的令牌端点总是会导致以下错误响应：
AADSTS50027：JWT 令牌无效或格式错误
根据 Microsoft 的文档，此错误可能有多种原因：
- 不包含 nonce 声明、子声明
- 主题标识符不匹配
- idToken 声明中的重复声明
- 意外的发行人
- 意外的观众
- 不在有效时间范围内
- 令牌格式不正确
- 来自颁发者的外部 ID 令牌签名验证失败。
在尝试了解有关 Azure 和 JWT 不记名流的更多信息时，我能够找到的唯一可靠信息是这篇文章： https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow
它描述了“代表”(OBO) 流，据我所知，它是 JWT 承载流的扩展（由微软？），将第二个 JWT 与一个名为“requested_token_use”设置为“on_behalf_of”。我只能找到与特殊OBO流程相关的“requested_token_use”，它的唯一值似乎是“on_behalf_of”。
OBO 流不是我们想要的，因为它似乎允许服务 X 将服务 Y 接收到的令牌转换为另一个令牌，使用 Y 令牌和自生成的 X 令牌来调用令牌端点。我们的用例只有一个自行生成的 X 令牌和允许该应用模拟的用户的名称。
经过漫长的试错阶段，我们得出的印象是 OBO 实际上可能是 Azure 知道的唯一（非标准）JWT 承载流版本，并且它可能不支持“正常“我们正在尝试使用的 JWT 不记名流。这是正确的吗，当涉及到 Azure 时，我们别无选择，只能放弃尝试使用标准 OIDC 解决这种情况，或者 Azure 实际上是否也支持我们已经实现的流程，而我们只是做错了什么（例如错误我们的 JWT 中的受众或发行者，还是 Azure 中配置错误的应用程序）？
PS：我们的代码是用 Java 编写的，我们使用 Nimbus 库进行 OAuth/OIDC 通信。
【问题讨论】：
标签： azure oauth-2.0 jwt openid-connect