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.