Konubinix' opinionated web of thoughts

OAuth 2.1

fleeting

A compilation of the main RFCs around OAuth 2.0 along with best practices.

Like for example

What’s new with OAuth2.1 with Aaron Parecki

Aaron Parecki, OAuth 2.1

the purpose of OAuth 2.0 was to avoid that the client oauth 2.0 sees the resource owner’s password

what is not OAuth 2.0 is not useless or a bad idea

from 5 grant flow to 2

authorization code grant with PKCE

The new way of getting the access token compatible with web clients.

Using a random value as a commitment that is eventually checked by the authorization server when sharing the access token.

Because it is hashed when first submitted, sharing its raw value in the end provides the proof that the client is still the same, even though the authorization code was given over a front channel.

Hence, it is like the authorization code flow, but with a client secret generated on the fly.

On the other hand, you still cannot hide the client_id and stuff like API that behave differently depending on the client cannot be sure the client_id was not stolen. You still need BFF for those kind of things.

Use this grant type for applications that cannot store a client secret, such as native or single-page apps

— https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-proof-key-for-code-exchange-pkce

Single-page appsCannot securely store a Client Secret because their entire source is available to the browser.

— https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-proof-key-for-code-exchange-pkce

A lot of flow in oauth 2.0 where defined, but eventually only two are left

  1. password grant for service to service non interactive communication
  2. authorization code grant with PKCE for interactive communication

pkce replaces the state

They were meant to do two different things.

  1. the state hold state data along the flow,
  2. pkce ensure the client that initiated the flow is the one that closes the flow,

Yet, to do pkce, you have to setup some session storage to provide the secret at the end of the flow. Therefore, doing pkce makes using the state useless.

it discourage to run a full web client

Instead, one should use a backend for frontend, because with XSS, there is no certainty that the code is secure. And all efforts to reduce the attack impact should be used.

it mostly removed stuffs from OAuth 2.0

use an exhaustive list of redirect uri in exact match

So that there is no way to use a client id and get an access token without having access to the redirect uri.

OAUTH 2.1 expliqué simplement (même si tu n’es pas dev)

Uses the metaphor of the hotel.

using pkce does not prevent from using the client secret

Both where developed while thinking about different issues, they end up overlapping a lot, bot not totally.

The client secret proves the identity of the client. But application that cannot protect a secret, like the single page applications, should not use it.

Notes linking here