AWS ALB集成Entra OIDC：v2.0令牌与UserInfo端点冲突问题

核心问题拆解 #

你当前的矛盾点：

• 需要无nonce字段的v2.0令牌以通过后端JWT验证，这要求使用自定义API作用域+requestedAccessTokenVersion=2配置
• 调用UserInfo端点时，要求令牌的aud字段为Microsoft Graph默认应用ID，但自定义作用域生成的令牌aud为你的应用ID，导致认证失败

以下是三种可直接落地的解决方案：

方案1：调整ALB转发令牌类型（推荐） #

根源在于混淆了ID Token与Access Token的用途：

• ID Token：用于身份认证（ALB验证用户合法性），OIDC规范要求其包含nonce字段
• Access Token：用于API授权，v2.0版本的自定义API Access Token无nonce字段，完全适配后端验证要求

具体操作：

1. 保留Entra应用的requestedAccessTokenVersion=2配置，自定义API作用域正常设置
2. 在AWS ALB的OIDC认证配置中，将转发给后端的令牌类型改为Access Token（而非默认的ID Token）
3. ALB作用域仍设为openid api://<app-uri>/<scope-name>
   • ALB通过openid作用域完成身份认证（使用ID Token），ID Token已包含profile/email等用户信息，无需调用UserInfo端点
   • 后端拿到的是自定义API的v2.0 Access Token，无nonce字段，验证直接通过

方案2：修改后端JWT验证逻辑 #

若业务必须使用ID Token（比如后端需从令牌提取用户身份信息），只需调整验证规则：

1. 保持Entra应用的requestedAccessTokenVersion=2配置，作用域设为openid profile email
2. 修改后端JWT验证逻辑，忽略令牌头部的nonce字段，不将其纳入校验项
3. v2.0版本的ID Token结构更规范，适配成本远低于v1.0，调整后即可兼容

方案3：双令牌配置（仅当必须调用UserInfo时使用） #

若业务上必须调用UserInfo端点，可配置同时获取Graph API与自定义API的令牌：

1. 在Entra应用的Delegated权限中，添加Microsoft Graph的User.Read权限并完成授权
2. 在AWS ALB的OIDC作用域中，同时配置：openid profile email api://<app-uri>/<scope-name> User.Read
3. Entra会返回两个Access Token：
   • 一个针对自定义API（aud为你的应用ID，供后端验证使用）
   • 一个针对Microsoft Graph（aud为00000003-0000-0000-c000-000000000000，用于调用UserInfo端点）
4. 配置ALB将自定义API的Access Token转发给后端，同时使用Graph的Access Token完成UserInfo调用

内容的提问来源于stack exchange，提问作者Khwaja Mohammad