Duende Blog

We recently attended NDC Oslo and had a great time chatting with current and future Duende IdentityServer customers. During the event, an individual approached us with an interesting dilemma and wondered if we could help them solve it.

They wanted to automate a UI test against their deployed instance of Duende IdentityServer but avoid using an end-to-end library like Selenium or Playwright, because those libraries depend on a headless browser like Chromium or Firefox. Can we test that first-party logins work properly entirely through .NET Code?

Luckily, brilliant folks work at Duende, including our Director of Engineering, Damian Hickey, who was able to write a simple console application simulating a browser. Still, with the recent announcement of .NET 10’s dotnet run app.cs, we thought we could provide this value through a script that is easily editable and runnable from any environment with .NET 10 available.

When working with user authentication in ASP.NET Core, you may encounter situations where you need to pass additional information through the authentication process. For example, you might want to track specific user actions, ensure they are redirected to a particular page after logging in, or pass custom parameters to an identity provider.

The AuthenticationProperties class provides an elegant solution for these scenarios. It allows you to carry state through call sites within a specific request, maintain state throughout the authentication process, or pass additional parameters to the identity provider you are using.

In this post, we'll see how to use the AuthenticationProperties class effectively in your ASP.NET Core applications and explore some OpenID Connect-specific options you can use in your apps.

Like all technological achievements, individuals' cumulative efforts and contributions lead to something great. The current state of application security results from many talented individuals who take security seriously, coming together to build a technology from which we all benefit. Without them, we’d likely all be building bespoke security solutions with varying levels of vulnerability and interoperability. Thank goodness for standards!

In this post, we take a trip down memory lane and explore some of the standards created over the last 15 years, both in the IETF and the OpenID Foundation, that make OAuth and OpenID Connect what they are today.

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.

While it has been around for a while, today is a good day to officially launch the Duende Developer Community! Whether you use Duende IdentityServer, BFF, or our open source tools, the Community is a place where you can connect with peers, share your knowledge, showcase your projects, participate in discussions, and more.

Let's take a look.

An essential part of ASP.NET Core’s authentication and authorization implementation is the ClaimsPrincipal class. Duende IdentityServer issues claims using the OpenID Connect protocol, and your ASP.NET Core applications transform the results into a ClaimsPrincipal instance used throughout your web applications.

Once you have an authenticated user, the fun starts, as you’ll want to make logical decisions about which resources the user can access. One of the more important places to make decisions is your user interface, where you may want to show elements based on authorization policies in your solution.

In this post, we’ll look at implementing an AuthorizationPolicyTagHelper to keep your Razor Views free of noisy C# flow constructs and discuss performance considerations that can make your pages feel even snappier.

At Duende Software, we value open-source software and the contributors who dedicate their time and passion to providing solutions for the development community. Many of our engineering team contribute to .NET’s open source software (OSS) ecosystem, with over 50+ million downloads and counting of packages directly authored by our team members.

As a community, sharing reusable functionality helps the community succeed. Still, it comes at a cost to maintainers that can make it unsustainable, whether in time spent, financial costs, or other burdens.

We want to help those maintainers ease the burden of developing OSS software and managing a growing community because when they succeed, we all succeed in delivering solutions. This is why, next to directly contributing to .NET projects, we also want to sponsor and promote Open Source projects actively. Each quarter, the Duende team nominates and votes on projects they wish to support.

We’re happy to announce the first recipient of such sponsorship: Shouldly.

At Duende Software, we are using Shouldly in the test suites of all our products, including IdentityServer and the Backend For Frontend (BFF) Security Framework - we're big fans! Let's look at how you can get started with Shouldly.

When building web applications, single-page framework applications have become one of the dominant forms of user experience creation. Developers have many choices, including React, Angular, Vue, and many more. While plenty of frameworks exist, only a few options exist for securing these applications.

At Duende, we recommend that developers adopt the Backend for Frontend (BFF) pattern to maintain a high-security posture and protect their users and data from malicious attacks.

In this post, we’ll look at the basic architecture of a BFF solution, the responsibilities of each component, and how it all fits together.