SPA使用Microsoft Entra授权码流获取Token时遭遇CORS错误求助

排查与解决步骤 #

1. 严格匹配重定向URI #

检查Microsoft Entra应用注册中的重定向URI，必须和你Token请求里的redirect_uri参数完全一致——包括协议（http/https）、域名、端口、路径，连末尾的斜杠都不能差。比如前端实际用的是https://your-app.com/auth/callback，注册里就不能写成https://your-app.com/auth/callback/。

2. 核对应用Manifest配置 #

进入应用注册的Manifest编辑器，确认：

• spa节点下的redirectUris数组包含你的重定向URI，无拼写错误：

  "spa": {
    "redirectUris": ["https://your-app.com/auth/callback"]
  }
  

• oauth2AllowIdTokenImplicitFlow和oauth2AllowImplicitFlow都设为false（授权码流+PKCE不需要隐式流，开启可能干扰CORS策略）。

3. 修正Token请求参数 #

• 把scope=.default换成具体权限，比如openid profile offline_access——.default可能触发不必要的权限校验，导致CORS拦截。
• 确保code_verifier和生成code_challenge时的原始随机字符串完全一致，不要有编码或截断错误。
• 检查client_id、grant_type=authorization_code等参数是否完全匹配应用注册信息，没有大小写或字符错误。

4. 浏览器请求的关键注意事项 #

• 不要手动设置Origin头，浏览器会自动发送当前页面的Origin，手动设置会被浏览器安全策略拦截，或者被Entra的CORS规则拒绝。
• 查看Chrome Network面板的OPTIONS预检请求：
  • 如果OPTIONS返回403，说明Entra还没同步你的域名配置，等待10-15分钟再试（Entra配置变更可能有延迟）。
  • 如果OPTIONS成功但POST仍报错，再仔细核对POST参数的完整性。

5. 清除浏览器缓存与Cookie #

旧的身份验证会话缓存可能导致异常，清除login.microsoftonline.com相关Cookie和页面缓存后重新测试。

关于Postman测试的矛盾点 #

Postman不受浏览器同源策略限制，手动设置的Origin头会被Entra服务器直接接受，但浏览器环境下的CORS校验更严格，必须完全符合SPA客户端的配置要求，不能用Postman的测试逻辑套到浏览器上。

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