SPA集成Azure AD获取token报CORS错误及开发方向咨询

你碰到的CORS报错不是配置失误导致的，是Azure AD认证端点的设计级安全限制：
Azure AD的v2.0 token交换端点本身不会向从浏览器端直接发起的裸AJAX跨域请求返回Access-Control-Allow-Origin响应头，所有试图在SPA前端用fetch/axios直接发POST请求换ID token、access token的操作，都会被浏览器的同源策略直接拦截。这是协议设计上为了防止前端代码泄露认证凭证的保护机制，不属于异常报错。

参照OIDC协议文档的大方向是正确的，但大概率在文档解读时混淆了不同客户端类型的适用流程：

• OIDC协议对单页应用（SPA）类的公共客户端，要求必须使用授权码流程+PKCE校验机制，全程不允许在前端代码中存储客户端密钥，也不推荐手动编写原生HTTP请求调用token端点
• 当前手动直接调用token端点拿token的操作，本身就偏离了SPA场景的标准实现路径，触发CORS是必然结果

• 废弃所有手动编写的、直接向Azure AD token端点发AJAX请求换token的代码逻辑，改用微软官方维护的MSAL.js SDK完成全流程认证：SDK内部会按照OIDC规范实现授权码+PKCE的交互流程，通过重定向/弹窗的安全交互完成授权码获取和token交换，匹配Azure AD对合法SPA来源的CORS放行规则，从根源上避开token端点的拦截问题。
• 回到Azure AD的应用注册后台，在身份验证板块为你的应用添加单页应用类型的重定向URI，把本地开发地址（如http://localhost:你的前端端口）、生产环境域名全部录入对应列表——注意不要选择Web应用类型的重定向分类，只有单页应用分类下的URI配置才能和MSAL.js的调用规则匹配，获得正确的CORS放行权限。
• 调用Microsoft Graph API时，确认申请的access token的scope覆盖了需要调用的Graph接口权限（如User.Read），Graph API本身会对携带合法access token的跨域前端请求返回正确的CORS响应头，不会出现同类拦截问题。

如果不想使用官方SDK，必须保持自定义认证逻辑，需要把token交换环节从前端挪到自有后端服务上：

• 前端通过OIDC重定向流程拿到授权码后，将授权码传递给自有后端接口
• 由后端服务发起服务器到服务器的请求，向Azure AD的token端点完成token交换（服务器请求不受浏览器CORS规则限制）
• 后端校验请求合法性后，将access token返回给前端，用于调用Graph API
  这种路径完全合规，但需要额外维护后端服务，不适合纯静态的无后端SPA场景。

• 不要通过关闭浏览器CORS安全策略的方式调试，这种方法只能解决本地开发的拦截问题，线上环境依旧会触发报错，还会掩盖认证流程本身的配置错误
• 绝对不要在前端代码中嵌入Azure AD应用的客户端密钥，这会违反SPA类应用的安全规范，哪怕绕过了CORS拦截，后续的认证请求也会被Azure AD的安全机制拦截

内容的提问来源于stack exchange，提问作者m.gg