- External reference: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08
- External reference: https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-proof-key-for-code-exchange-pkce
Like for example
Native applications are clients installed and executed on the device used by the resource owner (i.e., desktop application, native mobile application). Native applications require special consideration related to security, platform capabilities, and overall end-user experience
The best current practice is to perform the OAuth authorization request in an external user agent (typically the browser) rather than an embedded user agent (such as one implemented with web-views)
Before initiating the protocol, the client must establish its registration with the authorization server. The means through which the client registers with the authorization server are beyond the scope of this specification but typically involve the client developer manually registering the client at the authorization server’s website after creating an account and agreeing to the service’s Terms of Service, or by using Dynamic Client Registration ([RFC7591]).¶
Client authentication allows an Authorization Server to ensure it is interacting with a certain client (identified by its client_id) in an OAuth flow.
Authorization Server might make policy decisions about things such as whether to prompt the user for consent on every authorization or only the first based on the confidence that the Authorization Server is actually communicating with the legitimate client.¶
single client_id SHOULD NOT be treated as more than one type of client.¶
a client secret, sometimes known as a client password
Access tokens generally fall into two categories: reference tokens or self-encoded tokens.
Reference tokens can be validated by querying the authorization server or looking up the token in a token database, whereas self-encoded tokens contain the authorization information in an encrypted and/or signed string which can be extracted by the resource server.¶
. Don’t store bearer tokens in HTTP cookies
Implementations MUST NOT store bearer tokens within cookies that can be sent in the clear (which is the default transmission mode for cookies). Implementations that do store bearer tokens in cookies MUST take precautions against cross-site request forgery
authorization server SHOULD NOT process authorization requests automatically without user consent or interaction, except when the identity of the client can be assured. This includes the case where the user has previously approved an authorization request for a given client ID – unless the identity of the client can be proven, the request SHOULD be processed as if no previous request had been approved.¶ Measures such as claimed https scheme redirects MAY be accepted by authorization servers as identity proof. Some operating systems may offer alternative platform-specific identity features that MAY be accepted, as appropriate.¶
Wide deployment of this and similar protocols may cause end-users to become inured to the practice of being redirected to websites where they are asked to enter their passwords. If end-users are not careful to verify the authenticity of these websites before entering their credentials, it will be possible for attackers to exploit this practice to steal resource owners’ passwords.¶
What’s new with OAuth2.1 with Aaron Parecki
- External reference: https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd
from 5 grant flow to 2
authorization code grant with PKCE
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
it mostly removed stuffs from OAuth 2.0
use an exhaustive list of redirect uri in exact match
OAUTH 2.1 expliqué simplement (même si tu n’es pas dev)
- External reference:
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
- hydra: the OIDC layer
- Introduction to OAuth and OpenID Connect
- Julien Topçu
- OAuth 2
- OAuth 2 with Single-Page Apps
- OAuth 2.0 for Browser-Based Apps
- OAuth 2.0 Playground
- OAuth It s complicated
- OAuth Sketch Notes Q&A - PKCE, Scopes, Security, Passwordless
- OAuth the good Parts Dominick Baier
- OWASP API Security Top 10 Course – Secure Your Web Apps
- Protect Your APIs with OAuth
- public client
- Which OAuth 2.0 Flow Should I Use?