MS Graph无用户访问流程中如何验证微软响应的真实性

你担心的伪造回调导致跨租户恶意绑定的风险是真实存在的，仅靠state参数做ID映射无法完全防御，以下是生产环境验证过的可行方案，核心原则是永远不要被动信任回调请求携带的参数，所有绑定操作必须经过主动校验：

• 先做state参数的基础防伪造校验
  不要把state设置成内部租户ID和微软租户ID的静态映射值，每次发起管理员授权请求时，单独生成128位以上的高熵随机字符串作为state，把这个值和当前请求的内部上下文、10-15分钟的过期时间存在服务端缓存里。回调到达时第一步就校验state是否存在、是否在有效期、是否匹配发起请求时的上下文，校验不通过直接返回403，这一步能挡住绝大多数批量扫描构造的伪造请求。
• 主动调用接口校验授权真实性（核心校验，必做）
  哪怕state校验通过，也绝对不能直接用回调里带的tenant参数做ID绑定。你需要用自己应用的客户端凭证，主动向微软身份平台发起客户端凭证流的令牌请求，目标租户填回调传入的tenant值，请求格式如下：

  POST /{回调传入的租户ID}/oauth2/v2.0/token
  Content-Type: application/x-www-form-urlencoded
  
  client_id=你的应用客户端ID
  &client_secret=你的应用客户端密钥
  &scope=https://graph.microsoft.com/.default
  &grant_type=client_credentials
  

  • 如果令牌请求返回权限错误，说明对应租户根本没有给你的应用授予过管理员同意，直接终止流程即可
  • 如果成功拿到有效访问令牌，再带着这个令牌调用Graph的组织信息查询接口，确认返回的租户ID和回调传入的tenant值完全一致，这时候再执行内部租户ID和微软租户ID的绑定操作
• 可选辅助校验：来源IP过滤
  你可以定期同步微软公开的Azure身份服务IP段，校验回调请求的源IP是否在合法范围内，这一层可以提前过滤掉明显的伪造流量，但绝对不能作为唯一校验依据：一方面IP段存在更新延迟，另一方面攻击者同样可以在Azure内租用资源发起请求，绕过IP校验。

避坑提醒：不要靠User-Agent、Referer这类HTTP请求头判断请求来源，这些字段都可以被任意伪造，完全没有安全校验价值。

这套逻辑可以完全阻断你提到的攻击路径：攻击者就算能伪造出带受害者租户ID的回调请求，既拿不到你服务端缓存的合法state值，也没法让你方应用成功拿到受害者租户下的有效令牌——只有当租户管理员真的在微软官方授权页面完成了对你应用的同意操作，你主动发起的令牌请求才会成功，从根源上避免了错误绑定的问题。

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