已推荐用PKCE防攻击，为何仍需使用OAuth 2.0 PAR？

当客户端已经计划使用PKCE时，PAR（推送式授权请求，RFC9126）依然能带来不少实用价值，远不止减少浏览器负载这一点：

• 彻底解决URL长度限制问题：如果授权请求包含大量scope、自定义业务参数或客户端元数据，很容易触发浏览器、代理服务器的URL长度上限（比如部分旧浏览器仅支持2000多字符）。PAR通过后端POST请求提交完整授权参数，返回的request_uri是短字符串，从根源上避免了这类问题。

• 提升敏感参数的保密性：授权请求中的敏感内容（如自定义断言、精细权限范围）如果放在URL中，可能被浏览器历史、服务器日志、中间代理留存。PAR用POST传输这些参数，能降低敏感信息泄露的风险，和PKCE形成安全互补——PKCE防授权码拦截，PAR防请求参数泄露。

• 提前拦截无效请求：PAR请求会先经过授权服务器的合法性校验（参数格式、客户端权限、scope有效性等），如果存在错误能直接返回响应，不用等到用户跳转至授权页面后才发现问题。这既优化了用户体验，也避免了无效请求进入后续流程带来的潜在风险。

• 强化请求完整性：PAR生成的request_uri和原请求内容是绑定的，授权服务器只会处理与该URI匹配的请求。就算攻击者获取到request_uri，也无法篡改原请求的核心参数（如scope、redirect_uri），进一步加固了授权流程的安全性，这是PKCE无法覆盖的场景。

• 适配复杂业务场景：比如后端服务需要动态生成授权请求（根据用户实时权限调整scope），或者客户端为前后端分离架构时，PAR可以让后端先构造并验证完整请求，再将短request_uri传给前端跳转，简化了前后端协作逻辑，同时保持请求的安全性。

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