IdentityServer 6.3 and DPoP Support

In our last post we discussed the history and security properties of proof of possession access tokens.

While MTLS has been supported for several years now, our upcoming IdentityServer 6.3 release adds support for DPoP as well. This is very timely because DPoP Revision 16 has been approved by the IESG last week and will be an official RFC very soon.

Adding DPoP to you architecture requires code changes at every level in you system: the authorization server, the clients and the APIs.

To make the transition as seamless as possible, we made the effort to add DPoP support across the board to our client libraries, the Microsoft OpenID Connect handler, and the JWT token API plumbing.

Let’s have a brief look one by one.

IdentityServer 6.3

IdentityServer has a complete and fully compliant implementation of DPoP. It knows how to process and validate DPoP proof tokens, and if received will issue access tokens with the corresponding cnf claim.

Additionally you can set the RequireDPoP property on the client definition to force the usage of DPoP on a per client basis. We also added default implementations of iat and nonce based validation, can accomodate client and server clock skews and added a replay cache for proof tokens.

We published a release candidate earlier this week, and expect to release the final version within the next two weeks. DPoP is an Enterprise Edition feature.

samples | docs | nuget

Duende.AccessTokenManagement v2

Adding DPoP in clients is not entirely trivial, especially when the authorization server and APIs enforce server side nonces.

We already had a free library for automated client-side token management for both machine to machine clients and interactive clients using the ASP.NET OpenID Connect authentication handler. For v2 we added DPoP support as well.

The goal was to keep the client code changes as minimal as possible, and indeed all you need to start using DPoP in an existing client application that uses our token management is to configure a JSON web key.

builder.Services.AddOpenIdConnectAccessTokenManagement(options => 
{            
   options.DPoPJsonWebKey = jwk;
});

samples | docs | nuget

IdentityModel 6.1

IdentityModel is the underlying library for all of our products. It is now also DPoP aware by allowing to set proof tokens on OAuth endpoint requests as well as it includes constants for all DPoP related claims, error codes and scheme and header names.

var response = await client.RequestClientCredentialsTokenAsync(new()
{
   // rest omitted
  
   DPoPProofToken = "jwt"
});

nuget

IdentityModel.OidcClient

One of the very compelling motivations for DPoP is making mobile/native clients more secure. In those scenarios public clients need to send bearer tokens over untrusted networks and the chance of eavesdropping or token leakage is in general much higher.

At the same time, native clients typically have access to all the necessary crypto libraries to produce keys and proof tokens as well as access to secure storage on the device. Perfect match for DPoP.

We will soon release a DPoP add-on for our popular RFC8252/OpenID Connect RP compliant client library. Stay tuned for a separate announcement.

ASP.NET Web API Support

And last but not least, the APIs need to be DPoP aware. That functionality can be added on top of the extensibility model of the Microsoft JwtBearer authentication handler. You can choose on a per authentication scheme basis if DPoP and bearer tokens are supported, or DPoP tokens only.

services.ConfigureDPoPTokensForScheme("token", options =>
{
   options.Mode = DPoPMode.DPoPOnly;
});

We decided to provide this as a sample for now, maybe this will get turned into a Nuget package in the future.

sample | docs