JWKS is cached for jwtclientassertion authentication using private_key_jwt

[atjohn-csam]

Expected Behavior
The NimbusJwtDecoder should not be cached. If it has to be cached it should honor cache-control header in the response of jwks end point.

Current Behavior
NimbusJwtDecoder is cached in JwtClientAssertionAuthenticationProvider. Even if the client rotates its jwks, spring doesnt handle it.

Context
we had been using jwt client assertion authentication for oauth2 logins.
The client sends the cache-control header in the jwks response, but authorization server doesnt honor it and caches the keys.
As a work around i went ahead and created a custom authentication provider, but i would really appreciate if it can be handled in the JwtClientAssertionAuthenticationProvider.

[jgrandja]

Thanks for the report @atjohn-csam.

We're planning some work in gh-643 that will allow JwtClientAssertionAuthenticationProvider to be customized. We will likely expose a configuration where the application can customize the supplied JwtDecoder.

I'll keep this issue open until gh-643 is resolved.

[jgrandja]

@atjohn-csam

Even if the client rotates its jwks, spring doesnt handle it.

I just tested (simulated) the client rotating it's key and this is handled as expected in JwtClientAssertionAuthenticationProvider.

To test this out on your end, please follow these steps:

1. Checkout the branch jwt-client-authn
2. Start up the samples in this order: default-authorizationserver, messages-client, messages-resource
3. Put a break point at JwtClientAssertionAuthenticationProvider
4. Put a breakpoint at JwkSetController (client's JwkSet)
5. Login to the application. NOTE: The client's JwkSetController is called
6. Perform the authorization_code grant. NOTE: The client's JwkSetController is NOT called because the same key is used to sign the Jwt assertion so it uses the cache - this is indicated by the kid header
7. Now restart the messages-client application and it will generate a new Jwk and assign a new kid. This essentially is simulating key rotation on the client.
8. With the browser still open, perform the client_credentials grant. NOTE: The client's JwkSetController is called because kid in the Jwt assertion is not in the cached JwkSet in JwtClientAssertionAuthenticationProvider so it fetches the JwkSet on client side again.

IMPORTANT: When you rotate keys, the kid must be assigned a new unique identifier. If you use the same kid for the initial key and next key then it won't be fetched from the client JwkSet.

I'm going to close this as the current behaviour works as expected. However, if you still feel there is an issue, please provide a minimal reproducible sample and I can take a look at it.