OAuth and Proof of Possession Access Tokens

One of the most controversial decisions when OAuth 2.0 was being designed was the omission of a mechanism to cryptographically bind access tokens to clients. In favor of simplicity, only the Bearer token type was specified with the firm plan to add sender constraining at a later point.

This assumes “perfect” security at all the actors of an OAuth system including the wires that connect them. In an ideal bearer token world, there would be no leakage of access tokens at the client, resource, or the authorization server, and all network connections are end-to-end secured with no opportunity of eavesdropping for an attacker (see here for a summary of threats and mitigations).

Especially when you came from the WS-* era (or even OAuth 1.0), this seemed like a significant step back in available security features. What happened?

For some historical context, both WS-Security and OAuth 1.0 were specified in times where TLS could not be assumed. They both tried to mimic the same authenticity, integrity and confidentiality features that we get nowadays from our transport. This is very complicated to achieve at the message level and introduced involved crypto and key management. But even then, they could not solve all the problems.

When OAuth 2.0 was designed, TLS was considered widely deployed and thus mandatory. This lowered the attack surface considerably and most of the IETF spec authors opted for a simpler solution (and a shorter time to market): bearer tokens.

This was a very controversial decision and the main spec author decided he doesn’t want to be associated anymore with this protocol, got his name removed, and consequently left the working group.

As a consequence, the OAuth 2.0 specification was split into token acquisition (RFC 6749) and token usage (RFC 6750), where bearer tokens were the only option provided initially. There was a firm plan to deliver a solution for sender constraining shortly after the main spec was finally published. But it turned out that the problem was hard to solve with manageable complexity.

Several attempts were made around HTTP signing (very similar to OAuth 1.0) at the message level and HTTP token binding (a TLS extension) at the transport level. All failed for one or the other reason. Google’s announcement to not support token binding in Chrome was the final nail in the coffin for these efforts.

Fast forwarding, OAuth 2.0 became the industry standard and was being adopted in high security environments like banking and health care, and emerging standards like FAPI/PSD2 or FHIR demanded stronger protection of access tokens beyond bearer tokens and TLS.

The IETF was now under pressure to deliver a standard that would satisfy those requirements, and as a stop gap solution, proof of possession tokens using MTLS was specified and released, and defines a mechanism to bind a token to a TLS client certificate. This was motivated by the fact that those target environments (especially banks) typically already had existing PKI and MTLS infrastructure in place, and could with relatively low effort re-use those technologies to adopt proof of possession tokens.

For others, MTLS introduced significant deployment challenges, and especially when used over the internet, was not an option.

An alternative was needed that could combine TLS and reasonably simple signing at the message level – enter DPoP.

DPoP – or “OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer” adds the concept of binding tokens to a JSON Web Key using a short-lived detached signatures (so called proof tokens) over some aspects of the HTTP request combined with replay protection and transport security. The DPoP standard is in its “final call” phase and will soon be released as an RFC.

While IdentityServer has supported MTLS for several years now, DPoP support will be added in our upcoming 6.3 release in 2023 Q2. The feature is currently in preview.

We will add more detailed information on DPoP in upcoming blog posts, documentation and samples while we get closer to the release.

In summary proof of possession adds significant security properties for access tokens (if you need them), but does not come for free. Both MTLS and DPoP add complexity to your OAuth system that needs to be considered. In IdentityServer we offer both options to make it the tool of choice for environments with those higher security requirements.