OAuth 2.0 Pushed Authorization Requests

🔥More exclusive content: https://productioncoder.com/you-decid...
Twitter:   / _jgoebel  
Website: https://jangoebel.com
Blog: https://productioncoder.com
PAR RFC: https://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.