在前后端分离架构日益普及的今天，JWT 作为无状态身份凭证被广泛采用，但跨域场景下的验证流程、CORS 预检机制以及令牌自动刷新策略往往成为工程实现的痛点。浏览器同源策略严格限制跨域请求的资源访问，而 JWT 令牌需要在不同域名、不同端口甚至不同协议的服务间安全流转，这对代理层的架构设计提出了更高要求。本文将系统阐述 JWT 跨域验证代理的设计要点，给出具体的工程参数与实现建议。
跨域场景下的 JWT 验证核心参数
JWT 跨域验证的首要任务是确保令牌的完整性与有效性不因跨域传输而受损。服务器在接收到携带 JWT 的请求时，必须执行严格的验证流程，而非简单解码后直接放行。验证环节应包含四个核心维度：签名验证、过期时间检查、发行者校验与受众校验。签名验证是 JWT 安全体系的基石，应在服务端使用与发行时一致的算法重新计算签名，并与令牌携带的签名进行比对。任何算法不一致或签名不匹配的情况都应立即拒绝请求，同时记录详细日志以便后续安全审计。
过期时间验证通过检查令牌载荷中的 exp 声明实现，该声明以 Unix 时间戳形式表示令牌的失效时刻。工程实践中，建议将访问令牌的有效期设置为 15 至 30 分钟，以缩短令牌泄露后的攻击窗口。发行者验证通过检查 iss 声明确认令牌由可信的身份提供者签发，受众验证通过 aud 声明确保令牌的目标接收方与当前服务一致，这两层校验能有效防止令牌在不同服务间的误用或重放攻击。值得注意的是，CORS 预检请求（OPTIONS 方法）不会携带 JWT 令牌，因此代理层必须在验证逻辑中明确放行 OPTIONS 请求，仅对实际业务请求执行完整的 JWT 验证流程。
CORS 预检请求的处理机制
浏览器在发送跨域复杂请求前会自动触发 OPTIONS 预检请求，用于确认服务器是否允许该跨域操作。预检请求的本质是浏览器与服务器之间的安全协商，其请求头中包含请求方法（如 PUT、DELETE）和自定义头（如 Authorization）等信息。关键的安全设计在于，预检请求本身不会携带任何用户凭证，包括 JWT 令牌，这一设计避免了敏感认证信息在预检阶段的不必要暴露。
代理层处理 CORS 预检请求时，应返回正确的 CORS 响应头。Access-Control-Allow-Origin 头必须指定精确的前端域名，而非使用通配符 *，生产环境中使用通配符将导致安全审计不通过。Access-Control-Allow-Headers 头需要显式声明允许的请求头名称，特别是 Authorization 头，以确保携带 JWT 的正式请求不会被浏览器拦截。Access-Control-Allow-Methods 头应涵盖业务所需的全部 HTTP 方法，避免因方法限制导致预检通过但正式请求失败的情况。合理设置 Access-Control-Max-Age 头可以缓存预检结果，减少重复 OPTIONS 请求对服务器的压力，建议设置为 86400 秒（即一天）以优化性能。
在技术实现层面，代理层应将 OPTIONS 请求与业务请求分开处理。预检请求直接返回相应的 CORS 头后结束响应，不应进入 JWT 验证流程。正式请求则按照标准流程提取 Authorization 头中的 Bearer Token，执行完整的验证逻辑。这种职责分离的设计不仅符合 CORS 规范，也避免了因预检请求无凭据导致的验证失败。
自动刷新机制与令牌生命周期管理
JWT 的短有效期设计虽然提升了安全性，但也带来了频繁重新认证的用户体验问题。自动刷新机制通过引入双令牌体系解决这一矛盾：短效的访问令牌（Access Token）用于 API 调用认证，有效期通常为 15 至 30 分钟；长效的刷新令牌（Refresh Token）用于在访问令牌过期后获取新令牌，有效期可设置为 7 至 14 天或更长。这种分离设计使得短效访问令牌的泄露风险可控，而长效刷新令牌则存储在后端或通过安全方式管理。
刷新流程的核心是令牌的自动续期逻辑。当前端检测到访问令牌即将过期（建议在过期前 5 分钟触发刷新）或收到 401 响应时，应自动调用专用的刷新端点，携带刷新令牌请求新的访问令牌。服务器端验证刷新令牌的有效性后，生成新的访问令牌返回给客户端。为防止刷新令牌被盗用，建议实施令牌轮换策略：每次成功刷新后，服务器同时颁发新的刷新令牌并使旧令牌失效，这一机制显著降低了令牌泄露后的持续危害。
刷新令牌的安全性还需要额外的防护措施。服务器端应维护刷新令牌的撤销列表（黑名单），支持在用户主动登出或管理员干预时使指定令牌失效。结合令牌 ID（jti 声明）可以实现重放攻击防护，服务器记录已使用的令牌 ID，拒绝重复提交的同一令牌。监控层面应关注刷新失败的频率与来源，异常的刷新请求模式可能预示着令牌盗窃或暴力破解攻击。
代理层的工程落地参数
在具体实现中，代理层需要配置一系列工程参数以平衡安全性与性能。以下是建议的核心参数配置：
对于 JWT 验证环节，算法白名单应限制为 HS256、HS512、RS256 或 ES256，明确排除 none 算法与未知算法。密钥管理建议使用环境变量存储，避免硬编码；生产环境应实施密钥轮换机制，建议每 30 天更换一次签名密钥，同时保留旧密钥一段时间以支持过渡期的令牌验证。验证超时时间建议设置为 100 毫秒，避免因验证逻辑阻塞影响响应性能。
对于 CORS 配置，origin 白名单应动态维护，禁止在生产环境使用通配符。Access-Control-Max-Age 建议设置为 86400 秒，Access-Control-Allow-Credentials 应设为 true 以支持凭证传输。预检请求的处理应独立于业务中间件，确保无状态验证逻辑不干预 OPTIONS 请求。
对于刷新机制，刷新令牌的有效期建议设置为 7 天，访问令牌有效期建议设置为 15 分钟。刷新请求应实施速率限制，建议每分钟不超过 10 次，来自同一 IP 的异常刷新请求应触发临时封禁。刷新端点应仅接受 POST 方法，携带刷新令牌而非访问令牌，响应中应包含新令牌的过期时间以便客户端倒计时触发下次刷新。
安全传输与监控要点
JWT 的安全传输必须建立在 HTTPS 基础之上，任何通过 HTTP 传输的 JWT 都面临中间人攻击的风险。代理层应强制重定向 HTTP 请求至 HTTPS，并在响应头中设置 Strict-Transport-Security，指示浏览器在指定时间内仅通过 HTTPS 访问。Authorization 头是 JWT 的标准传输位置，应避免将令牌放置在 URL 参数中，以防日志泄露或历史记录暴露。
监控体系是安全保障的重要补充。代理层应记录所有验证失败的请求，包括失败原因、请求来源与时间戳，便于安全事件回溯。令牌刷新成功率应作为核心指标监控，持续下降可能意味着令牌盗窃或配置异常。跨域预检请求的频率与来源分布也应纳入监控，异常的预检请求模式可能预示着恶意扫描或 CORS 配置滥用。
资料来源
本文核心参数参考自 JWT 安全最佳实践指南（jwt.app）以及 Auth0 官方刷新令牌机制文档（auth0.com）。