Don't attach a stale client-assertion error description to unrelated token errors

[JoeShook]

Problem

When a client assertion fails UDAP validation, UdapJwtSecretValidator records an error description in HttpContext.Items. UdapTokenResponseMiddleware then injects that description into any 400 token response that has none of its own.

Duende runs secret validators as a composite, so another ISecretValidator can still authenticate the client afterwards (for example, private_key_jwt against a registered JWKS, with no x5c). The stale description then leaks into unrelated errors. A revoked refresh token, for instance, comes back as:

{ "error": "invalid_grant", "error_description": "Client assertion JWT validation failed" }

That points the client at its authentication, which was fine, rather than at the grant.

Fix

• UdapJwtSecretValidator: an assertion with no x5c header is not a UDAP client assertion. The validator now declines it quietly, without recording a description, and leaves the decision to the next validator.
• UdapTokenResponseMiddleware: the stored description is injected only when the error is invalid_client. Injection of authorization-extension extensions is unchanged.

Tests

New tests in AuthorizationExtensionEnforcementTests:

• Another secret validator authenticates the client, then a bad refresh token is presented. The response is a plain invalid_grant with no description. Without the fix, this test fails with "Client assertion JWT validation failed".
• An authorization-extension validator returns invalid_grant with error extensions. The response still carries its error_description and extensions.

The existing TokenRequest_TamperedJwt_Returns_InvalidClient_With_ErrorDescription test still shows that a real UDAP assertion failure returns invalid_client with the description.

UdapServer.Tests: 369 passed, 3 skipped.

🤖 Generated with Claude Code