Duende IdentityServer 7.2.0 Release Now Available

A busy week here at Duende! After yesteday’s release of Duende BFF Security Framework V3, we’re happy to announce the release of Duende IdentityServer 7.2.0, which includes enhancements, bug fixes, and new features. This post will discuss some of the most notable changes and how you might want to use them in your current deployments.

The IdentityServer 7.2.0 release comes with several changes we discussed in the IdentityServer 7.2 preview 1 post:

  • Do not issue TokenIssuedFailureEvent for use_dpop_nonce error
  • Use AsyncServiceScope in Background Services
  • Use query-safe URL fragment when returning an error
  • Add an option for strict validation of assertion audiences
  • General improvements to XML documentation and null reference exception handling

The IdentityServer 7.2.0 release adds some notable changes on top. Let’s have a look!

Preview Features

In 7.2.0, we are introducing the concept of Preview Features into Duende IdentityServer. They allow users to opt into experimental enhancements and improvements. These preview feature flags enable us to solve problems and give us the flexibility to receive customer feedback and change implementation details in a future release.

As a user, you can enable preview features with feature flags marked as previews. The addition of preview features combines our desire to iterate quickly and the value that stability provides. You can enable and disable these features more easily without managing different packages, CI/CD pipelines, or builds. Deploy and toggle features into any environment with the simplicity of a configuration change or toggle.

Two notable preview features in this release include Strict Audience Validation and Discovery Document Caching.

Strict Audience Validation

Private Key JWT authentication has a theoretical vulnerability where a Relying Party trusting multiple OpenID Providers could be attacked if one of the OpenID Providers is malicious or compromised. The attack relies on the OpenID Provider setting the audience value of the authentication JWT to the token endpoint based on the token endpoint value found in the discovery document. The malicious OpenID Provider can attack this because it controls what the discovery document contains and can fool the Relying Party into creating authentication JWTs for the audience of a victim OpenID Provider.

The IETF OAuth working group is working on a two-part fix in RFC 7523 bis: strictly validate the audience and set an explicit typ header in the authentication JWT.

Before this errata no typ was mandated, so the presence of the explicit typ provides a mechanism for understanding the client’s intention. When the typ header is set to client-authentication+jwt, strict audience validation is performed. When the typ header is not present, the old audience validation rules are applied.

In IdentityServer 7.2 preview 1, we started applying strict audience validation when the StrictClientAssertionAudienceValidation option is set, but didn’t do anything with the typ header. In this final 7.2 release, we’ve added support for the typ header checking. Now clients can opt in to strict validation by setting the typ header, or IdentityServer can enforce strict validation with the flag.

As this change is still somewhat experimental, we have moved the new StrictClientAssertionAudienceValidation flag that enables this behavior into the preview settings.

options.Preview.StrictClientAssertionAudienceValidation = true;

Check the strict audience validation documentation for more information.

Discovery Document Caching

Conversations with customers have revealed situations where the discovery document endpoint is forced to handle a higher-than-expected load. The increased requests can lead to memory pressure and strain on server resources. The increase in requests can come from some common architectural choices:

  • A solution with many clients, such as native (mobile) clients, SPA clients, or microservices that connect directly to the identity provider.
  • Disabling of Response caching on the clients

We’ve enabled a preview feature that allows you to cache the endpoint output using your distributed cache registration, with the default cache being an in-memory implementation. The cache is meant to reduce pressure when a sudden spike in requests occurs.

You must set the following property in your IdentityServerOptions instance to enable discovery document caching:

pipeline.Options.Preview.EnableDiscoveryDocumentCache = true;
pipeline.Options.Preview.DiscoveryDocumentCacheDuration = TimeSpan.FromMinutes(1);

It’s best to keep the cache time low if you utilize the CustomEntries element on the discovery document or implement a custom IDiscoveryResponseGenerator.
This feature is a step in optimizing Duende IdentityServer to utilize server resources and improve performance. More benchmarking and tuning will follow.

Bug Fixes

We have fixed a behavioral bug thanks to our developer, Brett Hazen. This change occurred when a contribution inadvertently altered the behavior of IdentityServer and how cookies are re-issued.

Conclusion

Thank you for your continued support. We look forward to your feedback on this release. Feel free to comment on this post or join the discussion in our community forum. If you’d like to upgrade now, you can find all the most recent releases on NuGet, and the source is available on our GitHub repositories. Also, visit Duende GitHub discussions for the latest community conversations.