Image for post
Image for post

The OAuth Working Group recently adopted the Pushed Authorization Requests (PAR) draft as working group document, which is an important step on its way to become an RFC. PAR improves the robustness and security of the OAuth code flow in a very simple way.

Instead of sending all authorization request parameters through the browser, the client first pushes the payload of an authorization request to the authorization server via a direct request and is provided with a request URI that is used as reference to the data in the subsequent authorization request.


Initiating an OAuth authorization is simple. Just build a URL with a few parameters and open it in a browser (or send the user to this destination via HTTP redirect). Its simplicity is one of the cornerstones of the success of OAuth. …

It’s been a while since I blogged about the new challenges arising from open banking and other use cases when it comes to OAuth authorization requests.

Meanwhile, I have been entertaining my ideas with a lot of smart people in the community, combined it with existing proposals, such as the FAPI work on pushed request objects and, and teamed up with great co-authors to write up concrete specifications.

And here they are:

  • OAuth 2.0 Rich Authorization Request (RAR): introduces the request parameter „authorization_details“ that will carry an array of JSON objects, each of them containing the authorization data for a certain API or resource. …

Image for post
Image for post

Have you ever come across limitations of the way OAuth expresses the requested scope of an access token? Well, I have several times in the course of the last couple of years in the areas of open banking and remote electronic signature creation.

Let’s take the example of a payment authorization: If you want to authorize a payment using OAuth, you need to pass amount, currency, recipient, and purpose to the authorization server. Otherwise, the authorization server cannot gather the user’s consent for that particular transaction and mint an access token that is really constrained to the transaction’s parameters (e.g., the amount). …

Image for post
Image for post

No one should any longer use the implicit grant! That’s what IETF’s OAuth working group, the authority for official OAuth specifications, recommends in the upcoming OAuth 2.0 Security Best Current Practice RFC. The decision was met during the IETF meeting this week in Bangkok.

Here is what the working group document says:

The implicit grant (response type “token”) and other response types causing the authorization server to issue access tokens in the authorization response are vulnerable to access token leakage and access token replay …

In order to avoid these issues, Clients SHOULD NOT use the implicit grant and any other response type causing the authorization server to issue an access token in the authorization response. …


Torsten Lodderstedt

Torsten is, software architect with strong security interest, identity nerd, contributor to OAuth, OpenID, Open Banking & Electronic Signatures

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store