github DuendeSoftware/products is-7.2.0
IdentityServer 7.2.0
on GitHub

one day ago

IdentityServer 7.2 is a significant release that includes:

  • Optional strict validation of private_key_jwt audiences, implementing RFC 7523 bis
  • Optional caching of the discovery endpoint
  • Less log noise when issuing the use_dpop_nonce response from the token endpoint
  • Bug fixes and optimizations

Upgrading

There are no breaking changes or schema updates required to upgrade from IdentityServer 7.1 to 7.2.

Upgrading from IdentityServer 7.2.0-preview.1

We have moved the StrictClientAssertionAudienceValidation option that was introduced in 7.2.0-preview.1 into a new Preview section of the options. This new section provides a mechanism for us to deliver new features more quickly, and gives us the flexibility to change implementation details, behavior, or the API surface. Users can opt in to preview features at their own discretion, with the understanding that we make a stronger commitment to API stability once a feature leaves preview. Our intent with Preview flags is to be able to iterate quickly while still providing stability.

We've decided to mark StrictClientAssertionAudienceValidation as a preview option since the formal specification that it is based on (RFC 7523 bis) has not yet been adopted by the IETF OAuth working group.

RFC 7523 bis

RFC 7523 bis is a proposed update to RFC 7523 in which two new requirements for private_key_jwt client assertions are proposed:

  • That the audience (aud claim) must be the issuer of the authorization server and must be a single string
  • That the type (typ header) must be "client-authentication+jwt"

Similar strict audience validation requirements can be found in the FAPI 2.0 Profile.

The intent of the audience validation is to prevent certain academic attacks against OAuth ecosystems that include multiple Authorization Servers in which one of the Authorization Servers is compromised or malicious. The new type header value provides a mechanism to facilitate upgrades, because conforming clients that adopt the proposed changes will produce a token that can be easily distinguished by looking for the new type.

IdentityServer 7.2 includes preview support for RFC 7523 bis. Client applications can opt in to this support by setting the new type header; assertions that set the typ header to client-authentication+jwt always have their audience validated strictly. Other clients can continue to authenticate with private_key_jwts as they do today. IdentityServer can be configured to force clients to update by setting the option options.Preview.StrictClientAssertionAudienceValidation. When that flag is enabled, all private_key_jwt client assertions must set the typ to client-authentication+jwt, and must set their audience to the IdentityServer's issuer.

Discovery Document Caching

We've heard reports of cases where a high volume of requests to the discovery endpoint caused memory pressure and strain on server resources. This could happen in a solution with many clients calling the discovery endpoint, such as native (mobile) clients, SPA clients, or microservices that connect directly to the identity provider. It could also happen if misconfigured clients fail to cache the discovery response.

We’ve added 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: 

#pragma warning disable DUENDEPREVIEW001
pipeline.Options.Preview.EnableDiscoveryDocumentCache = true;
#pragma warning restore DUENDEPREVIEW001
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.

use_dpop_nonce Log Noise Reduction

One way to configure DPoP is to require a server-issued nonce value. A nonce prevents replay or pre-generation of the proof tokens used in DPoP by having the authorization server provide a nonce value that the client must include in its signatures. That nonce is provided to the client through a protocol error response.

In IdentityServer 7.1 and earlier, this raised the TokenIssuedFailureEvent because, technically, the token endpoint returns an error. However, this interaction is an expected part of the interaction between client and server. It isn’t an error in the usual sense of the word, and it can happen quite often, resulting in lots of noise in the logs. Therefore, we no longer raise the TokenIssuedFailureEvent when returning a server-generated DPoP nonce.

For those still interested in knowing these errors are occurring, we have added additional Debug log messages to help diagnose and troubleshoot your client implementations. Because these messages are low severity, you must explicitly enable them in your environments to see them. The existing OTel metrics that track token error responses are unchanged, as they don’t add noise to the logs.

Detailed changelog

Check out latest releases or
releases around DuendeSoftware/products is-7.2.0

Don't miss a new products release

NewReleases is sending notifications on new releases.

Get notifications