这个问题在企业级B2C集成项目里其实挺常见的，我结合实际落地经验来聊聊两种方案的取舍和最佳实践：

方案1：使用API自有Microsoft Graph凭据 #

这是大部分场景下的首选方案，优势很明显：

• 权限集中管控：你只需要给API对应的服务主体配置必要的Graph权限（比如User.ReadWrite.All，严格遵循最小权限原则），不用给每个调用方应用单独分配Graph权限，避免权限扩散带来的安全风险。
• 流程简化：验证完调用方的JWT（校验app roles、自定义claims等）后，直接用API自己的凭据调用Graph即可，不需要额外的令牌交换逻辑，代码更简洁，维护成本更低。
• 审计清晰：所有Graph操作都来自同一个服务主体，在Azure AD的审计日志里能快速追踪到所有用户变更操作的来源，排查问题更高效。

需要注意的是：API层的JWT验证必须严格，比如要确认调用方的app role包含UserManagement这类允许修改用户的角色，同时校验其他必要的claims（比如租户ID、应用ID），确保只有授权的应用才能发起变更请求。

方案2：通过令牌交换获取调用方绑定的Graph令牌 #

这种方案适合有特殊业务需求的场景：

• 适用场景：如果你的合规要求需要将Graph操作的身份关联到具体调用方，或者不同调用方应用本身有差异化的Graph权限（比如A应用只能修改普通用户，B应用能修改管理员用户），这时可以采用On-Behalf-Of（OBO）令牌交换流程，获取以调用方应用身份访问Graph的令牌。
• 劣势：流程复杂度高，需要实现OBO流的令牌交换、缓存、刷新逻辑，增加了代码维护成本；同时权限管理分散，每个调用方都需要配置对应的Graph权限，容易出现权限配置错误或过度授权的情况；审计时需要关联API调用日志和Graph操作日志，排查问题更麻烦。

总结建议 #

• 绝大多数业务场景下，优先选择使用API自有Microsoft Graph凭据，它更符合安全管控的最佳实践，也能降低开发和维护成本。
• 只有当你有明确的业务需求需要以调用方身份执行Graph操作时，才考虑使用令牌交换的方式。

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