Spring Authorization Server中PAR流程的request_uri有效期问题解析

在OAuth 2.0的Pushed Authorization Request（PAR）流程中，Spring Authorization Server实现存在一个关于request_uri有效期的设计缺陷。本文将深入分析该问题的技术背景、产生原因以及解决方案。

问题背景

PAR是OAuth 2.0的一个扩展规范，它允许客户端将授权请求参数预先推送到授权服务器，获得一个request_uri用于后续的标准授权端点调用。在Spring Authorization Server的当前实现中，request_uri的有效期被硬编码为30秒。

问题本质

问题的核心在于授权流程中的双重验证机制：

1. 当客户端首次调用/authorize端点时，系统会验证request_uri是否过期
2. 在用户完成认证后，Spring Security会将用户重定向回原始授权请求，此时系统会再次验证request_uri的有效性

这种设计导致了一个潜在问题：如果用户认证过程（特别是包含多因素认证等复杂流程时）耗时超过30秒，第二次验证就会失败，即使第一次验证时request_uri仍在有效期内。

技术影响

这种实现方式可能带来以下影响：

1. 用户体验下降：用户可能在完成复杂认证流程后被意外拒绝
2. 与RFC 9126规范的潜在不一致：规范未明确说明expires_in是否应覆盖整个授权流程
3. 系统灵活性不足：固定30秒有效期无法适应不同安全要求的场景

解决方案演进

项目维护者提出了分阶段解决方案：

短期方案

将硬编码的有效期从30秒延长至5分钟，这足以覆盖大多数认证场景的时间需求。

长期优化方向

1. 实现有效期可配置化：通过配置属性或DSL方式允许开发者自定义有效期
2. 优化验证逻辑：避免在认证完成后的重定向阶段重复验证有效期
3. 明确规范实现：更精确地遵循RFC 9126对PAR流程的定义

最佳实践建议

对于正在使用或计划使用Spring Authorization Server PAR功能的开发者：

1. 及时升级到包含修复的版本（2025年6月17日后的版本）
2. 对于需要更严格安全控制的场景，建议后续关注有效期配置功能的实现
3. 在系统设计中考虑认证流程的预期时长，确保留有足够的时间余量

总结

这个问题揭示了在实现安全协议时需要考虑完整用户旅程的重要性。Spring团队快速响应并提出的分层解决方案，既提供了立即可用的修复，又规划了长期的架构改进，体现了成熟开源项目的处理方式。对于开发者而言，理解这类底层机制有助于构建更健壮的安全认证系统。