OpenID Connect中PAR授权请求生命周期的疑问及原理咨询

一、PAR的实际工作原理 #

推送授权请求（PAR）是OAuth 2.0的扩展，核心是把原本放在重定向URL中的长授权请求先通过POST方式提交给授权服务器，换取一个短标识，具体流程：

• 客户端将完整授权参数（如client_id、scope、redirect_uri等）通过POST请求发送到授权服务器的PAR端点。
• 授权服务器验证请求合法后，返回一个request_uri（对应原始授权请求的唯一标识）和expires_in（该标识的有效期，规范要求5-600秒）。
• 客户端引导用户重定向到授权端点，此时URL只需携带request_uri（无需再传大量参数）。
• 授权服务器通过request_uri调取存储的原始授权请求，继续完成用户认证、授权同意等流程，最终返回授权码给客户端。

二、用户未认证场景的处理方案 #

针对request_uri过期、重复使用的问题，可通过以下方式解决：

1. 合理设置request_uri生命周期 #

规范仅建议尽可能缩短有效期，但并非强制要求最短值。根据实际场景调整：

• 若存在MFA、新用户注册等可能耗时的流程，直接设到规范上限600秒（10分钟），平衡安全性与用户体验。
• 普通登录场景可设为120-300秒，既避免过长时间的暴露风险，也给用户足够的登录操作时间。

2. 服务器端会话绑定授权上下文 #

不要让登录页直接携带request_uri跳转，而是由授权服务器做以下处理：

• 当用户未认证时，授权服务器先验证request_uri的有效性，然后将对应的原始授权请求上下文（而非request_uri本身）绑定到用户的临时会话（如服务器端缓存存储）。
• 跳转登录页时，仅传递会话标识，不暴露request_uri。
• 用户登录完成后，授权服务器通过会话标识取出授权上下文，继续完成授权流程，之后标记原request_uri为已使用（避免重复调用）。

3. 强制request_uri单次使用的机制 #

授权服务器必须保证request_uri仅能被使用一次，因此在会话绑定上下文的基础上：

• 首次验证request_uri时，暂不标记为已使用，仅锁定该标识与当前会话关联。
• 只有当授权流程完整完成（用户授权成功/失败）后，才将request_uri标记为已过期或已使用，防止其他请求复用。

4. 备选方案：重新发起PAR请求 #

如果担心request_uri在登录过程中过期，客户端可在用户登录完成后，重新发起一次PAR请求，生成新的request_uri再跳转至授权端点。这种方式虽然增加了一次请求，但能彻底规避过期问题。

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