正在尝试确定OAuth 2.0推送授权请求RFC9126(https://datatracker.ietf.org/doc/html/rfc9126)的实用程序。在安全考虑部分，RFC讨论了请求URI交换攻击，声明如下：客户端应该使用PKCE ...来防止此攻击。如果客户机无论如何都要使用PKCE，那么我认为使用PAR的唯一好处就是稍微减少了给予给浏览器的有效负载。是否有我没有看到的额外好处？
slsn1g291#
一个好处是，客户端后端在允许开始身份验证之前通过POST请求对自身进行身份验证：
POST https://login.example.com/authorize/par client_id=myclient& client_secret=mysecret& redirect_uri=http%3A%2F%2Fwww.example.com%2F& scope=openid%20profile& response_type=code& response_mode=jwt& code_challenge=l9QIPE4TFgW2y7STZDSWQ4Y4CQpO8W6VtELopzYHdNg& code_challenge_method=S256& state=NlAoISfdL1DxPdNGFBljlVuB1GDjgGARmqDcxtHhV8iKNYu6ECS2KOavDHpI3eLN
另一个好处是，在前端通道上发送的浏览器请求受到保护，防止篡改。例如，通过man in the browser：
man in the browser
https://login.example.com/authorize? client_id=mylient& request_uri=urn:ietf:params:oauth:request_uri:7d353fc8-9b94-488f-8c61-cf7cc1dfef9e"
请注意，PKCE将继续使用，稍后将发送一个code_verifier来获取令牌，这证明完成身份验证的一方是启动身份验证的一方，这是标准做法。
code_verifier
1条答案
按热度按时间slsn1g291#
一个好处是，客户端后端在允许开始身份验证之前通过POST请求对自身进行身份验证：
另一个好处是，在前端通道上发送的浏览器请求受到保护，防止篡改。例如，通过
man in the browser：请注意，PKCE将继续使用，稍后将发送一个
code_verifier来获取令牌，这证明完成身份验证的一方是启动身份验证的一方，这是标准做法。