The second main feature of IdentityServer v6.3 is support for the Dynamic Client Registration (DCR) protocol. This is on one hand part of our ongoing journey to implement all relevant protocols from the OAuth and OpenID Connect working groups, but also the start of a bigger effort around adding programmatic configuration capabilities to IdentityServer. DCR really consists of a base specification (RFC 7591) and various add-ons defining additional client metadata elements.

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.

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

Cross-device flows enable a user to initiate an authorization flow on one device (the initiating device) and then use a second, personally trusted, device (authorization device) to authorize access to a resource (e.g., access to a service). These flows are increasingly popular and typically involve using a mobile phone to scan a QR code or enter a user code displayed on an initiating device (e.g., Smart TV, Kiosk, Personal Computer etc).

Every single OAuth/OIDC project needs a solution for token management in client applications at some point. It first sounds like a trivial thing, but it is surprisingly hard to get it right. We have been working on an access token management library for ASP.NET Core on the side for a couple of years now, and we also used it ourselves in our BFF security framework. And while re-visiting it recently, we realized it shows its age and needs some substantial work to maintain.

For our 6.1 we have added first class support for server-side sessions and better session management features. The Problem Normally when a user establishes an authentication session in the browser for an ASP.NET Core application, the state for that session is contained entirely within the cookie. This is also true for authentication sessions in Duende IdentityServer. This means, by default, it’s difficult to perform advanced session management tasks such as:

OpenTelemetry is a collection of tools, APIs, and SDKs for generating and collecting telemetry data (metrics, logs, and traces). This is very useful for analyzing software performance and behavior - especially in highly distributed systems. Now that the tracing part of OTel is finalized, we started adding instrumentation to all relevant parts of IdentityServer - especially around input validators, response generators and stores. The output is very useful for visualizing the control flow and finding performance bottlenecks.

Duende IdentityServer is a protocol engine and framework and does not include any UI. When it comes to UIs around your authentication workflow, we designed this to be an extensibility point, and our Quickstart UI gives you a very good starting point for your own implementation. When it comes to Admin/configuration UI capabilities, we always deliberately excluded that from the product. There are many different scenarios and approaches how you might want to integrate configuration/administration of IdentityServer in your system.

I am happy to announce that we have finished all the work on version 6 of IdentityServer! IdentityServer v6 is fully optimized for .NET 6 which is a long term support version and thus an ideal platform for your updated or new identity infrastructure. Just like .NET 6, we will support IdentityServer v6 for the next three years. What’s new From a high level point of view we did: Performance and stability improvements.

One of the most exciting aspects of turning our IdentityServer project into a real company is, that we are now in the position to employ people and get them work in a field they are passionate about. And that is especially true if these are people you highly respect and always wanted to work with! Damian Hickey is an old friend and joined our team to help us with consulting, training and software development.