隐式授权流中ID Token与Access Token的使用选择咨询

直接给结论：你应该使用Access Token来调用你的Web API，这是符合OAuth2和OpenID Connect规范的最佳实践，哪怕你的API是令牌的唯一消费者也不例外。

为什么不应该用ID Token？ #

ID Token的设计初衷是给客户端（你的Angular SPA）用的——它的核心作用是让客户端验证用户的身份，获取用户的基本信息（比如姓名、邮箱）。它的受众(aud)字段指向的是你的SPA的客户端ID，而不是Web API的。微软文档里反复强调的「ID Token不应替代Access Token用于授权」，本质上是在区分**身份验证（验证用户是谁）和授权（验证用户能做什么）**这两个完全不同的流程。

你看到的那些用ID Token调用API的示例，更多是为了快速演示端到端的认证流程，属于简化的演示场景，并不适合生产环境。

为什么必须用Access Token？ #

1. 符合令牌的设计意图：Access Token是专门为API授权而生的，它的受众(aud)是你的Web API的客户端ID（或应用ID URI），令牌中会包含API需要的角色声明，正好匹配你后端RBAC的需求。
2. 安全性更有保障：Access Token的生命周期可以更精细地配置，而且它的权限范围是限定在你的API上的——如果令牌不慎泄露，攻击者只能访问你的API，而不会影响到用户的其他身份相关操作。
3. 扩展性更强：如果未来你的API需要调用其他服务，或者你新增了其他API服务，基于Access Token的模式可以无缝扩展，不需要重构整个认证逻辑。

具体怎么做？ #

• 在MSAL.js的配置中，确保你请求的是你的Web API的专属范围，而不是只请求openid、profile这些OpenID Connect的基础范围。比如你的API范围可能是api://<你的API客户端ID>/access_as_user。
• 调用API时，通过MSAL的acquireTokenSilent或acquireTokenPopup方法，获取针对该API的Access Token，而不是直接拿ID Token。
• 后端API验证令牌时，重点检查：
  • aud字段是否匹配你的API的客户端ID/应用ID URI
  • 令牌的签发者(iss)是否可信
  • 令牌是否未过期
  • 角色声明是否符合当前请求的权限要求

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