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