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

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

— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08

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)

— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08

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]).¶

— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08

Client authentication allows an Authorization Server to ensure it is interacting with a certain client (identified by its client_id) in an OAuth flow.

— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08

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

— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08

single client_id SHOULD NOT be treated as more than one type of client.¶

— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08

a client secret, sometimes known as a client password

— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08

Access tokens generally fall into two categories: reference tokens or self-encoded tokens.

— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08

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

— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08

. 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

— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08

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

— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08

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

— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08

What’s new with OAuth2.1 with Aaron Parecki

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