Identity, Unlocked... Explained | Episode 1

The Overview

On the first episode of Identity, Unlocked, host Vittorio Bertocci, Principal Architect at Auth0, is joined by Brian Campbell. Brian joins the show to discuss the sender constraint and associated specifications.

The mechanism described by OAuth2 for using the access token to access resources, as defined in the bearer token usage specification (RFC6750), simply entails attaching a token to the request to the API. The approach is extremely simple to implement, but token leaks can have disastrous consequences: nothing stops an attacker from using a stolen bearer token to access a resource successfully.

"Sender constraint" indicates a series of techniques that bind tokens to a particular sender, for example, by forcing the token to travel on a specific channel or requiring proof of knowledge of a given key. The goal is to guarantee that only the legitimate sender can successfully use a token to access resources, thus making it impossible for an attacker to access a resource using leaked tokens.

There are two different specifications in the OAuth 2 family offering viable sender constraint capabilities today: OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens (MTLS, RFC8705) and OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP).

MTLS is robust and stable, but not easy to implement in various important scenarios. For a while, the identity community worked on an alternative, a set of specifications under the general token binding moniker (main one: RFC8471); however, support from key industry players disappeared or never materialized, making token binding non-viable.

DPoP quickly emerged as an easy to implement an alternative that could fill that gap, and although it is still in draft state, it is already very popular and making quick progress.

Brian touches on all those specs during the episode, walking us through the trajectory that led us to today's situation and taking the time to dig deeper into the trade-offs, strengths, and attention points of the various approaches. The episode concludes with important practical considerations to keep in mind when planning an implementation strategy for the sender constraint in your solutions today.

Read on for more in-depth information on this episode and make sure to subscribe and join us for the next episode, where Aaron Parecki (Senior Security Architect) talks about what's new with OAuth2.1.

Highlights:

In the following, we highlight key passages of the interview. We added some background information here and there to make it easier to follow the conversation if you aren't already familiar with the topic.

[4:45] - What is sender constraint and what problem is it trying to solve?

The figure below shows a typical OAuth 2 flow for calling an API- a good example to understand how bearer tokens are meant to work.

In the first leg of the diagram, a client requests an access token - this might be the redemption of an authorization code, of a refresh token, anything that leads to an access token being issued to the client as shown in step 2. In this particular example, we are issuing tokens that are digitally signed by the

authorization

In step 3, the client calls the API by simply attaching the access token to the request (typically by placing it in the authorization HTTP header).

In step 4, the API validates the incoming access token (in this example, that includes validating the signature with the public key associated with the authorization server), and the call succeeds.

The following diagram shows what happens when a bearer token is leaked.

In step 1, an attacker steals an access token. For the purpose of highlighting the problem with bearer token leaks, it doesn't matter how the leak occurs (the token might be leaked from a cache, a referral header, an HTTPS tunnel termination, erroneously forwarded to a malicious address etc., etc.) as it doesn't change the consequences of the leak. Once an attacker has the token, all they need to do to access the API successfully is to attach it to an API call - the API will perform the same validation we had observed in the former diagram when the call was originating the legitimate sender. This is the key limitation of bearer tokens: everything hinges on not making them fall into the wrong hands, as when that happens, there's no easy recourse.

[11:35] - What are the current standards with sender constraint?

The main specifications extending OAuth 2 with sender constraint capabilities are:

• MTLS (RFC8705)
• DPoP (DPoP)
• Token binding (RFC8471)

Token binding is mentioned out of exhaustiveness, but it isn't really a viable option as of today. For the other ones, we give more details later on in the interview.

[11:51] - Brian explains mutual TLS profile for OAuth 2.

Here's a super quick primer to explain how MTLS works in OAuth 2. This leaves out lots of details, so if you are interested, you should consider taking a look at the spec itself (RFC8705). Please consider the diagram below.

The client application has access to an X509 certificate, which it uses to perform client TLS authentication (hence proving possession of the corresponding private key) when requesting a token from the authorization server. The authorization server issues a token containing (or referencing, if other token encoding methods are used) a claim cnf carrying the thumbprint of the X.509 certificate used to establish the channel. Important note: the access token is still meant to be signed by the authorization server, and the API is still meant to validate that signature, but we are omitting it in all diagrams from now on for simplicity.

In step 2, the client establishes a channel with the API/resource server, again using its X509 certificate to establish client TLS.

In step 3, the API validates the incoming token as usual, and additionally, it verifies that the certificate thumbprint corresponds to the certificate used to establish the TLS channel. If the two matches, the call is considered valid.

Consider now the case in which an attacker successfully steals a token. The attacker does not have access to the same certificate as the legitimate client; hence it cannot establish a client TLS channel with the API when attempting to use the stolen token - or it has to use a different certificate. However, the API will easily spot that the certificate thumbprint carried by the cnf claim in the incoming access token does NOT correspond to the certificate used in client TLS authentication by the attacker; hence the API will deny access.

[15:32] - Brian explains DPoP.

To help you follow the discussion, here’s a diagram exemplifying how DPoP works.

The idea is simple: the client uses some keys when requesting a token, those keys are referenced by the access token issued by the authorization server, and the client demonstrates knowledge of the same keys to the resource server when using that access token to call an API. Let's break that down in the steps shown in the diagram.

The client generates a private-public keys pair. It then creates a JWT, called DPoP proof, including in it a claim

jwk

htu

https://server.example.com/token

htm

jti

iat

In step 1, the client attaches the DPOP proof in a DPOP HTTP header to a token request to the authorization server.

In step 2, the authorization server uses the public key in the

jwk

cnf

In step 3, the client calls the API. Using the DPoP, the client creates a new DPoP proof, including the same

jwk

htu

https://resource.example.org/protectedresource

htm

jti

iat

In step 4, the client validates the incoming access token as it would do in a normal bearer case. In addition to that, it validates the DPoP signature with the

jwk

cnf

jwk

[18:42] - If DPOP blossoms like some anticipate, is there any reason to continue mutual TLS?

[23:23] - Brian’s opinion on how DPoP can be rolled out.

Links/Resources:

Learn more about Brian Campbell
Brian Campbell on Twitter

Vittorio Bertocci on LinkedIn
Vittorio Bertocci on Twitter

Learn more about Identity, Unlocked
Learn more about Auth0