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 OAuth.xyz, 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. …

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). …

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. …