使用Postman通过授权码流程获取MS Graph访问令牌时出现invalid_grant错误

核心排查方向（按出现概率从高到低排序） #

• 授权码本身的有效性校验
  Entra ID签发的授权码默认仅5分钟有效，且为一次性凭证——只要该授权码被使用过一次（不管请求成功还是失败），或是获取后放置超时，都会直接触发invalid_grant报错。这类问题只需要重新走一遍授权页获取全新的授权码，在拿到码的1分钟内填入Postman发起令牌请求即可，不要存储、复用之前的旧授权码。
• 跨流程的参数强一致性校验
  授权码流和你之前用的客户端凭证流（无用户参与的应用权限流程）校验逻辑完全不同，必须保证取授权码、换令牌两个环节的核心参数逐字匹配：
  • 两个环节传递的redirect_uri必须完全一致，哪怕末尾多/少一个斜杠、http/https协议不匹配，都会触发校验失败
  • 换令牌时使用的client_id、client_secret必须和应用注册中的当前值完全匹配，之前轮换过密钥的话，旧密钥必然触发校验不通过
  • 换令牌时传递的scope范围，必须和取授权码时申请的offline_access user.read完全匹配，不能混入仅适用于客户端凭证流的应用权限scope
• 应用注册的流程适配配置缺失
  你之前的应用配置只适配了客户端凭证流，要走需要用户参与的委托授权流程，需要补全两类配置：
  • 应用注册的身份验证板块，要把配置的重定向URI https://localhost:8080归类到「公共客户端（移动和桌面端）」分类下，不能仅挂载在Web类重定向URI条目里——Postman属于本地客户端调用场景，URI类型不匹配会直接触发invalid_grant
  • API权限板块要确认申请的User.Read权限为委托类型权限，不要只配置了同名的应用类型权限：委托权限是授权码流的适用权限，应用权限是客户端凭证流的专属权限，两者权限体系互不通用
• 授权账号的租户匹配校验
  如果应用注册为单租户模式，授权环节登录的账号必须属于该租户下的工作/学校账号；如果授权时登录了跨租户的个人微软账号、或是同租户的其他域账号，签发的授权码和令牌请求的租户上下文不匹配，也会触发报错。

排错小技巧：遇到这类报错先逐字核对两个请求环节的参数一致性，再检查应用配置的适配类型，90%以上的报错都能快速定位，不需要优先排查网络或服务端故障。

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