We recently published Duende.AccessTokenManagement.OpenIdConnect 3.0.1, a security hotfix which addresses CVE-2024-51987, a medium-severity security issue that can cause refreshed access tokens to be cached and used for the wrong user.

We encourage everyone using Duende.AccessTokenManagement.OpenIdConnect 3.0.0 to update to version 3.0.1.

Today we are publishing two NuGet packages related to DPoP:

• Duende.IdentityServer 7.0.8, which addresses a low-severity security issue in our DPoP support for local APIs (CVE-2024-49755), and
• Duende.AspNetCore.Authentication.JwtBearer 0.1.3, the first preview of a new series of ASP.NET Core extensions that help you leverage advanced IdentityServer features - in this case DPoP support for APIs.

We encourage everyone using IdentityServer 7.0.0 and later to update to IdentityServer 7.0.8, but do note that most IdentityServer implementations are not affected. In this blog post, we’ll discuss the issue in more detail and the specific circumstances where this vulnerability applies, as well as show how to use the new package to implement DPoP in your ASP.NET APIs.

We think that PAR is one of the easiest ways to increase the security of OAuth and OpenID Connect. That’s why we prioritized the implementation of the RFC and released fully featured support in IdentityServer v7.

Unfortunately, it wasn’t as straightforward as it could be to add client-side PAR support to an existing ASP.NET Core application using the Microsoft OpenID Connect authentication handler.

Almost exactly four years ago we announced the big news of transitioning our free, open-source project, IdentityServer, to a commercial, source-available product.

As a part of that transition, we founded Duende Software as the new home for our products. Our main goal was to focus on IdentityServer – turning it into a sustainable product, improving the quality and reliability of our code base, and enhancing our samples, documentation and customer support.

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.