使用Graph API获取的AAD Token无法访问自有REST API，如何兼顾两者？

这确实是个常见的痛点——AAD的访问令牌默认是单一受众的，没法用一个Token同时搞定Graph API和你的自定义API，但完全不用让用户登录两次！除了嵌入客户端信息，这里有几个更优雅的解决方案：

1. 增量授权（Incremental Consent） #

这是最贴合用户交互场景的方案。用户第一次登录时，你请求Graph API所需的权限（比如User.Read），拿到对应的令牌。当需要访问你的自有API时，发起一个新的令牌请求，带上自有API的scope（比如api://{your-api-client-id}/user_access），同时加上prompt=none参数：

• 如果用户之前已经登录过，且已经授权过你的API权限，AAD会直接返回针对自有API的Token，完全不会弹出登录界面；
• 如果用户还没授权过你的API，只会弹出一个权限确认框，不用重新输入账号密码，体验流畅。

举个Auth Code Flow的请求示例：

GET https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize
?client_id={your-client-id}
&response_type=code
&redirect_uri={your-redirect-uri}
&scope=https://graph.microsoft.com/User.Read api://{your-api-client-id}/user_access
&prompt=none
&state={state-value}

如果用Refresh Token的话，直接用已有的Refresh Token请求新的scope，也能静默获取新的访问令牌，全程无用户感知。

2. 会话内多令牌管理 #

在你的应用中维护用户的登录会话（比如用Cookie或本地存储保存Refresh Token），当需要访问不同资源时，分别获取对应的访问令牌。因为有Refresh Token，你可以静默地为不同资源获取独立的令牌，用户完全察觉不到额外操作。这种方式需要你的应用做好令牌的缓存和区分存储（比如按资源ID分类保存令牌）。

3. 应用权限+客户端凭据流（后台场景适用） #

如果你的应用是无用户交互的后台服务（比如定时任务、批量处理），可以使用客户端凭据流获取应用级别的令牌。只要在AAD中给你的应用配置好Graph API和自有API的应用权限（而非委托权限），这个单一令牌就能同时访问两个资源。不过这个方案只适用于不需要用户上下文的场景，不适合前端或用户交互类应用。

额外提醒：尽量迁移到AAD v2.0端点，它推荐使用scope参数而非传统的resource，权限管理更灵活。同时要确保你的自有API在AAD中正确注册，配置好对应的scopes，用户授权后才能获取到访问它的令牌。

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