在AWS构建MS Teams应用：Azure作为第三方IdP的认证问题求解

架构老林

2026-7-10

解决方案分析与建议

关于前端直接用MSAL认证的问题

这完全没问题，前端通过MSAL直接和Azure AD完成认证获取令牌是合理路径。当前核心问题是AWS托管API需要适配这种认证方式，而非必须依赖Cognito用户池的用户身份。

完全可行，这是适配当前场景的直接解决方案，具体实现步骤如下：

在API Gateway中创建Token类型的自定义Lambda授权器，要求前端请求API时在Authorization请求头携带Azure AD颁发的ID Token或Access Token。
Lambda授权器核心逻辑：
1. 从请求头提取令牌，判断格式合法性。
2. 从Azure AD的公钥端点（如https://login.microsoftonline.com/{你的租户ID}/discovery/v2.0/keys）获取公钥，建议缓存公钥以提升性能。
3. 验证令牌核心字段：
  - 签名有效性：用公钥验证令牌签名，确保未被篡改。
  - 过期时间（exp）：确认令牌未过期。
  - 发行者（iss）：匹配你的Azure租户发行端点（如https://login.microsoftonline.com/{租户ID}/v2.0）。
  - 受众（aud）：匹配你的Azure AD应用注册的客户端ID。
4. 验证通过后，生成IAM策略文档，允许该用户访问指定API资源（示例策略结构如下）：
```
{
  "principalId": "azure-user-id",
  "policyDocument": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "execute-api:Invoke",
        "Resource": "arn:aws:execute-api:你的区域:你的账号ID:你的API ID/你的阶段/*/*"
      }
    ]
  }
}
```
5. 将策略返回给API Gateway，完成授权。

根据你的需求（无需在Azure部署资源、支持MS凭证登录），推荐以下几种方案：

优点：实现灵活，完全在AWS侧完成，无需Azure额外资源；前端可直接用MSAL获取的Access Token调用Microsoft Graph API，无需经过AWS中转。
注意事项：需自行处理令牌验证的异常情况（如令牌过期、无效签名等），并做好公钥缓存以减少外部请求开销。

适用场景：如果需要让用户通过Azure令牌获取AWS临时凭证（访问S3、DynamoDB等其他AWS服务），可将Azure AD作为Cognito联合身份池的身份提供商，同时用Lambda授权器处理API身份验证。
核心逻辑：前端用MSAL获取Azure ID Token后，调用Cognito联合身份池的GetId接口获取身份ID，再调用GetCredentialsForIdentity获取临时AWS凭证；API侧仍用Lambda授权器验证Azure令牌。
优点：兼顾AWS资源访问和API授权；缺点：配置略复杂，仍需处理令牌验证逻辑。

适用场景：如果需要统一管理用户对AWS资源和Microsoft服务的访问权限。
核心逻辑：将Azure AD作为IAM Identity Center的身份提供商，用户通过MS凭证登录后，可获取访问AWS资源的权限，同时保留Azure令牌用于调用Graph API。
优点：身份管理更统一；缺点：配置复杂度较高，需要启用IAM Identity Center服务。

调用Microsoft Graph API时，直接用前端MSAL获取的Access Token发起请求，无需经过AWS服务中转，这样能避免令牌传递问题，也更符合微软最佳实践。
如果需要存储用户信息，可在Lambda授权器验证通过后，用Azure用户的唯一ID（如oid字段）作为标识，将用户数据存储到DynamoDB等AWS数据库中，无需依赖Cognito用户池。

内容的提问来源于stack exchange，提问作者Daniel Cutter