JWT认证中Authorization、x-auth-token、x-access-token的差异及使用规范

三类请求头的核心区别与适用场景 #

• Authorization 标准请求头
  属于HTTP RFC 7235规范明确定义的标准认证头，有统一的格式要求：Authorization: <认证方案> <凭证内容>，JWT认证场景下通用格式为Authorization: Bearer <JWT字符串>。
  你提到的MDN文档描述的是浏览器原生处理Basic/Digest等传统HTTP认证的默认行为，仅在浏览器自发触发认证流程时才会先发送无凭证请求、收到401响应后再补带Authorization头。前后端分离架构下的前端代码（比如React的axios/fetch请求）是完全自主控制请求头的，主动在首次请求就携带Authorization头完全符合规范，不存在违规问题。
  适用场景：无特殊兼容需求的所有认证场景，是首选方案。优势是标准头不会被网关、CDN等中间件默认拦截，跨域时只要认证方案和值符合简单请求规则，不会额外触发OPTIONS预检请求。
• x-auth-token、x-access-token 自定义请求头
  这两个都属于非标准自定义头，前缀X-是早期约定的非标准头标识，没有统一的规范约束，用法完全由项目开发者自行约定。部分项目会自行约定x-auth-token用于登录阶段传递临时校验凭证，x-access-token用于传递登录后的访问令牌，也有大量项目二者混用，都用来传递JWT令牌。
  适用场景：仅在需要兼容旧系统自定义认证逻辑、或者项目需要同时承载两套独立认证体系时使用。缺点是属于自定义头，跨域请求必然触发OPTIONS预检，且如果中间件没有配置放行规则，可能会被直接过滤丢弃。

认证流程最佳实践 #

没有必要混用多种认证头，绝大多数场景下统一使用标准Authorization头即可，通用流程如下：

1. 客户端提交账号密码/验证码等凭证发起登录请求，该请求无需携带认证头
2. 服务端校验凭证有效后，返回访问令牌（access_token）和刷新令牌（refresh_token），客户端将二者存储在安全的位置（推荐HttpOnly Cookie，其次是localStorage/sessionStorage）
3. 后续所有需要认证的业务请求，前端主动在请求头中携带Authorization: Bearer <access_token>，无需等待401响应后再添加
4. 服务端校验令牌：如果令牌有效则正常返回业务数据；如果令牌过期/无效返回401状态码
5. 客户端收到401响应后，优先使用本地存储的refresh_token向服务端申请新的access_token，刷新成功后携带新令牌重发原请求；如果refresh_token也过期/无效，清空本地存储的令牌信息，跳转至登录页

如果项目有单独传递刷新令牌的需求，也可以自定义X-Refresh-Token头传递refresh_token，这一用法属于行业通用约定，没有合规问题。

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