oauth2-proxy令牌刷新重定向时丢失POST表单数据问题咨询

针对三个问题的明确结论 #

• 1. POST请求载荷在cookie存储模式下刷新令牌时丢失是组件的预期行为。
     cookie作为客户端存储方案时，oauth2-proxy只能把原始请求的URL、请求方法这类短信息编码后放在URL查询串的state参数里传递，受URL长度限制根本无法承载完整POST请求体；加上整个令牌刷新流程是靠多次302跳转实现的，浏览器默认不会在302跳转链路中保留原POST请求的载荷内容，即便state里记录了请求方法是POST，没有原始请求体也无法完整重建请求，这是cookie存储方案的天然设计限制，不是组件bug。
• 2. 只有使用服务端状态存储方案时才能保留POST请求载荷，目前官方原生支持的服务端存储只有Redis。
     配置Redis存储后，oauth2-proxy不会再把原始请求信息塞到state参数里传递，只会在state中放一个随机关联ID，完整的原始请求（包括URL、方法、请求头、POST请求体）都会存在Redis服务端；从IDP跳转回oauth2-proxy时，组件会通过state里的关联ID从Redis拉取完整原始请求信息，才能正确重建带表单数据的POST请求。注意该能力需要手动开启配置，默认配置下Redis存储也不会持久化POST请求体，需要打开原始请求体持久化相关开关。
• 3. 30分钟的访问令牌刷新阈值属于业界常规配置，完全不算短，靠拉长超时时间规避问题完全不可行。
     目前多数对安全有要求的系统访问令牌有效期设置在5-15分钟，30分钟已经属于偏宽松的配置。拉长令牌有效期不仅会显著提升令牌泄露后的安全风险，也无法彻底解决问题：只要用户停留在表单页面的时间超过令牌有效期，点击提交时依然会触发刷新跳转，POST数据丢失的问题还是会出现。

实践建议 #

• 优先切换状态存储方案：如果业务存在大量表单POST提交场景，直接部署Redis作为oauth2-proxy的服务端状态存储，同时开启原始请求体持久化配置，这是最稳妥、不需要改造业务代码的原生解决方案。
• 前端前置刷新兼容：如果暂时无法部署Redis，可以在前端表单提交逻辑里增加前置检查：提交POST请求前先发一个轻量的GET探活请求，判断令牌状态，如果发现令牌即将过期或已经失效，先静默完成令牌刷新，再发起真实的POST表单提交，从根源上避免提交请求时触发跳转刷新。
• 增加表单本地暂存兜底：对核心表单场景，前端可以把用户已填写的内容实时暂存到sessionStorage中，即便出现跳转导致页面重载，也能自动回填之前填写的内容，避免用户重复输入，这层兜底逻辑不受oauth2-proxy存储方案影响，能覆盖所有异常场景。
• 禁止为规避该问题拉长访问令牌有效期、关闭令牌过期校验逻辑，这类操作会带来明确的安全隐患。

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