OAuth 2.1
fleeting- External reference: https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-proof-key-for-code-exchange-pkce
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
- External reference: https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd
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
Single-page appsCannot securely store a Client Secret because their entire source is available to the browser.
A lot of flow in oauth 2.0 where defined, but eventually only two are left
- password grant for service to service non interactive communication
- authorization code grant with PKCE for interactive communication
pkce replaces the state
They were meant to do two different things.
- the state hold state data along the flow,
- 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)
- External reference:
- see,
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
- 5 types of grant -> now only 2
- Aaron Parecki
- client secret
- Forget about OAuth 2.0. Here comes OAuth 2.1 - Philippe De Ryck - NDC Oslo 2022
- front channel
- How to Hack OAuth
- Introduction to OAuth and OpenID Connect
- Julien Topçu
- OAuth 2.0 Playground
- OAuth in Five Minutes
- OAuth It s complicated
- OAuth Sketch Notes Q&A - PKCE, Scopes, Security, Passwordless
- OAuth the good Parts Dominick Baier
- Protect Your APIs with OAuth
- public client