Bump the duende group with 2 updates

[dependabot]

Bumps the duende group with 2 updates: Duende.IdentityServer and Duende.IdentityServer.Storage.

Updates Duende.IdentityServer from 7.1.1 to 7.2.0

Release notes

Sourced from Duende.IdentityServer's releases.

IdentityServer 7.2.0

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.

... (truncated)

Commits

• 25f74ef Merge pull request #1883 from DuendeSoftware/sf/remove-experimental-flags
• 9c05ed3 Removes the "Experimental" flags from the Preview options.
• e6f9993 Merge pull request #1860 from DuendeSoftware/sf/enforce-strict-audience-valid...
• a5c031d Updated test cases
• 273d22b Fixed comment.
• 554d420 Reverted from constant to string. Reworked token helper to produce a strict t...
• 91889e2 Updated use of constants
• 270e896 Reverted changes to replay test as they weren't relevent.
• ddaca52 Tweaked validation logic and added unit coverage.
• 5c0d208 Initial work
• Additional commits viewable in compare view

Updates Duende.IdentityServer.Storage from 7.1.1 to 7.2.0

Release notes

Sourced from Duende.IdentityServer.Storage's releases.

IdentityServer 7.2.0

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.

... (truncated)

Commits

• 25f74ef Merge pull request #1883 from DuendeSoftware/sf/remove-experimental-flags
• 9c05ed3 Removes the "Experimental" flags from the Preview options.
• e6f9993 Merge pull request #1860 from DuendeSoftware/sf/enforce-strict-audience-valid...
• a5c031d Updated test cases
• 273d22b Fixed comment.
• 554d420 Reverted from constant to string. Reworked token helper to produce a strict t...
• 91889e2 Updated use of constants
• 270e896 Reverted changes to replay test as they weren't relevent.
• ddaca52 Tweaked validation logic and added unit coverage.
• 5c0d208 Initial work
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[dependabot]

Dependabot cannot update to the required version. Because of this, Dependabot cannot update this pull request.

[dependabot]

Looks like these dependencies are updatable in another way, so this is no longer needed.