OAuth授权码流程为何采用302重定向传递授权码？

• 历史设计背景：服务端应用优先
  OAuth 2.0最初是为服务器端Web应用设计的，这类应用拥有独立后端服务器，能安全存储客户端密钥。重定向到后端回调地址后，后端可直接从URL参数获取授权码，再搭配密钥向IDP换取令牌——全程前端不会接触到敏感的密钥和授权码，完全契合早期Web应用的架构逻辑。

• 浏览器同源策略的适配
  早期浏览器的同源策略严格限制跨域XMLHttpRequest（XHR）请求，IDP与客户端通常分属不同域名，直接发起XHR请求会被浏览器拦截。而重定向是浏览器原生支持的跨域交互方式，不受同源策略约束，能顺畅完成从IDP到客户端的跳转流程。

• 用户认证会话的天然匹配
  用户在IDP的登录状态靠浏览器Cookie维护，重跳转过程中浏览器会自动携带IDP的Cookie，IDP可直接确认用户已完成认证。如果用XHR请求，即便配置withCredentials=true携带Cookie，也不符合早期Web依赖页面跳转完成认证的交互模式，用户无法直观感知认证流程的完成。

• 降低敏感数据泄露风险
  授权码属于敏感数据，若通过XHR响应体返回给前端，极易被XSS攻击窃取。早期授权码流程中，重定向的回调地址指向后端，授权码直接由后端接收，前端全程不接触该数据，从根源上减少了泄露可能性。后来针对SPA这类无后端场景，才引入PKCE来弥补前端处理授权码的安全漏洞。

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