Duende.AccessTokenManagement 3.0 is out now! Highlights of this release include:

• Improved support for Blazor Server
• Updates to dependencies
• Bug fixes and improvements

See the release notes for the full details, or read on for a quick summary.

Today we are publishing a hotfix for all supported versions of Duende.IdentityServer that addresses CVE-2024-39694, a moderate severity open redirect security vulnerability. We encourage everyone to update to the latest patch version. Note that by itself, this vulnerability does not allow an attacker to steal tokens or user credentials. An attacker would most likely exploit this vulnerability to make phishing attacks more likely to succeed.

We have also published a security advisory with technical details about the severity, affected versions, specific APIs involved, and work-arounds for those who can’t upgrade to a patched version.

In this blog post we’ll discuss open redirect vulnerabilities more generally, the process we followed to manage disclosure of the issue and patch, and lessons learned from that process.

Historically, IdentityServer could either issue reusable refresh tokens or enforce refresh token rotation. The default value was “rotate” which can often lead to problems. In IdentityServer 7.0, we made the decision to change the default behavior of refresh tokens so that they would be reusable by default. In this blog post, we’ll describe refresh tokens and their security in detail and explain why we made this choice.

Pretty much exactly one year after the release of IdentityServer v6, we are happy to announce our next major version: IdentityServer v7.

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.

We started our journey with Traces in Duende IdentityServer v6.1. .NET 8 has full support for Open Telemetry and so does Duende IdentityServer v7. IdentityServer emits traces, metrics and logs.

OAuth and OpenID Connect requests consist of two steps. The front channel for user interactions like login or consent, and the back channel for transmitting the resulting tokens into client client applications. Front channel requests are done via the browser to the so called authorize endpoint, and the way the protocol was designed, those requests typically contain a significant number of parameters to help the authorization server to optmize the user workflow.

Today marks the release of .NET 8. This is the new long-term support version of .NET and thus the perfect foundation for our next major version of IdentityServer. For this release we focused on three big feature areas compatibility and optimisations for .NET 8 adding support for RFC 9126 aka pushed authorization requests (PAR) adding OpenTelemetry metrics We are publishing a preview of v7 today and are planning to release the final version in early January.

The sweet spot for proof of possession access tokens is clients that are operated in untrusted networks and can securely store key material and tokens - very typically that tranlates to native mobile applications. We maintain an open source client library that implements RFC8252 (aka “AppAuth”) style authentication and token management. This library targets netstandard2.0 and thus is usable on all .NET platforms (e.g. Windows / Mac desktop, iOS, Android etc.

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.