IdentityServer offers multiple diagnostic possibilities. The logs contain detailed information and are great for troubleshooting, but we’re seeing a shift toward using OpenTelemetry to collect metrics, traces, and logs to help monitor and troubleshoot applications.

This post will examine OpenTelemetry, its use within Duende IdentityServer, and how to surface all necessary telemetry signals in the .NET Aspire Dashboard. Combining these powerful technologies gives you a world-class development experience that helps you rationalize and implement solutions correctly.

Many IdentityServer users are upgrading their deployments to the latest version of .NET and Duende IdentityServer. Most upgrades are uneventful and fair, with many users pleasantly surprised by a smoother-than-expected process. Successful deployments are excellent news! We love to hear that our care and attention to building a secure and stable product have led to a great developer experience.

Developers choose Duende IdentityServer over other commercial offerings because of its flexibility and almost infinite configurability. With great power comes great responsibility, and as developers, we all need to understand the consequences of our decisions. While these options are good in most cases, they can make performance investigations bespoke and time-consuming.

During the upgrade process, a handful of users reported a particular kind of performance degradation, which led our highly skilled and experienced customer success team to investigate.

The investigation has taken a few weeks of back-and-forth with customers, jumping on calls, and deep-diving into the Duende IdentityServer code and the .NET codebases. In this post, we’ll describe what our customers saw, the cause of the instability, and the solution.

ASP.NET Core web application development can span from entirely server-side rendered UIs to front-end single-page applications dominating the user experience. More often than not, you’ll likely have some client side code that fetches information from a backend resource, whether an endpoint or a multipurpose API. As the .NET Identity company, Duende recommends securing these calls, but you may be asking, how?

Security recommendations have evolved with the popularity of JavaScript and the initial explosion of single-page application frameworks. As of this post, the best current practices recommend developers secure their browser-based application with Backend For Frontend (BFF) and adopt a “no tokens in the browser” policy. Realizing that a browser client’s storage is a potential attack vector means malicious parties can target high-value resources such as refresh and access tokens stored locally, leading to compromised security models.

In this post, we’ll briefly recap the BFF pattern and then proceed to a sample of revealing your OpenAPI specifications to users either with Swagger’s UI or client SDK generators.

But first, let’s talk about BFF for folks who are first learning about the pattern.