OAuth 2.0 Pushed Authorization Requests

🔥More exclusive content: productioncoder.com/you-decid...
Twitter: / _jgoebel
Website: jangoebel.com
Blog: productioncoder.com
PAR RFC: www.rfc-editor.org/rfc/rfc912...
When authorizing a natural person with the authorization code grant in OAuth 2.0, the initial request parameters are sent via the browser's bar (front channel). This poses several challenges
1. no authenticity or integrity protection: an attacker might modify the requested scopes
2. no confidentiality in the user agent because the data passes unencrypted through the user agent (browser)
3. URLs can get quite long which might become a problem on mobile devices
Pushed Authorization Requests solve these challenges by adding an additional step before redirecting to the authorization server. Instead of passing the OAuth 2.0 parameters in the user's browser, the client makes a POST request to the authorization's Pushed Authorization Requests endpoint. The client sends the exact same parameters it would have sent in the browser's bar, but now in the back channel.
This has the advantage that the client's backend can authenticatie with the PAR endpoint. This can be with a client id and a client secret or by any other suitable means (e.g. mTLS would also work). In addition, the PAR endpoint may support JWT-secured authorizaton requests (JARs) so that the payload that is sent to the PAR endpoint can be signed or signed and encrypted.
The authorization server replies back with a unique request_uri. This request_uri is then passed in the browser's search bar (the front channel) when redirecting to the authorization endpoint. The remaining OAuth 2.0 flow stays as normal.

[@vladislavzubov2818]

Perfect explanation. Thank you for your work man!

[@jgoebel]

Glad it was helpful!

[@ArvindKumar-oz6jg]

If an attacker gets hold of the returned request-uri and client-id, there is no way for AS to determine whether the request coming to it is from right source?
Seems solved with MTLS client auth

[@jgoebel]

Pushed Authorization Requests essentially protect against a malicious app starting an OAuth flow and requesting more scopes than needed. Even if you do get the request URI, the end user still needs to authenticate. So PARs can add value in high security deployments.

[@ArvindKumar-oz6jg]

@@jgoebel are you active on LinkedIn, would like to connect

[@jgoebel]

@@ArvindKumar-oz6jg yes, the link is in the channel banner on the top right (the LinkedIn symbol) or on my website