OidcIdTokenDecoderFactory allows only one algorithm (default to RS256) to be specified for JWT Decoder. Doesn't work when there are multiple algorithms used by IDP to issue signed JWT Tokens

[jigneshshukla]

Describe the bug
OidcIdTokenDecoderFactory by default defines jwsAlgorithmResolver with RS256 as signature algorithm for Signed JWTs (here at

spring-security/oauth2/oauth2-client/src/main/java/org/springframework/security/oauth2/client/oidc/authentication/OidcIdTokenDecoderFactory.java

Line 86 in 1edfa07

private Function<ClientRegistration, JwsAlgorithm> jwsAlgorithmResolver = (

)

It provides a setter method to override and supply your own algorithm resolver (here at

spring-security/oauth2/oauth2-client/src/main/java/org/springframework/security/oauth2/client/oidc/authentication/OidcIdTokenDecoderFactory.java

Line 221 in 1edfa07

public void setJwsAlgorithmResolver(Function<ClientRegistration, JwsAlgorithm> jwsAlgorithmResolver) {

).

However, the way jwtAlgorithmResolver is being used to create NimbusJwtDecoder in buildDecoder() function (here

spring-security/oauth2/oauth2-client/src/main/java/org/springframework/security/oauth2/client/oidc/authentication/OidcIdTokenDecoderFactory.java

Line 140 in 1edfa07

private NimbusJwtDecoder buildDecoder(ClientRegistration clientRegistration) {

) , it enforces only one algorithm to be supplied to NimbusJwtDecoder which it uses internally during the key selection process.

This implementation works fine if IDP uses only one algorithm at a time as in that case, we can customize the algorithm to be used by supplying your custom jwtAlgorithmResolver using setJwsAlgorithmResolver() setter method.

However, if IDP uses more than one algorithms to sign ID Token, there is no way we can supply all the algorithms used by IDP and so the token processing fails during the whole OIDC based authentication process when a token is signed with a different algorithm than what's used to initialize NimbusJwtDecoder through OidcIdTokenDecoderFactory.

To Reproduce
Have IDP use more than one algorithm (say RS256 and ES256 both) to sign JWT and make sure it randomly alternates between these algorithms for oidc based authentication request flow.

Expected behavior
As long as user has authenticated successfully, the client app should be able to process and validate IDTokens regardless of which algorithm was used out of the set of configured algorithms.

Sample

Unfortunately, I can't share any code as it's private to the organization I work for, however, I'll update this ticket if I can somehow create a sample with some public IDP (e.g. google) where I can configure multiple algorithms.

[jgrandja]

@jigneshshukla I'm not seeing the issue you are having.

The Map of jwtDecoders is keyed by clientRegistration.getRegistrationId(), which means each ClientRegistration has it's own JwtDecoder instance.

A custom jwsAlgorithmResolver would receive a ClientRegistration and it should return the JwsAlgorithm that is expected to be used by the provider for the the ID Token signature. The key word to note is expected, because when a client is registered with a provider, part of it's registration metadata is id_token_signed_response_alg. Therefore, if the custom jwsAlgorithmResolver is configured correctly then there shouldn't be any issues with ID Token signature verification.

Can you provide more details or a minimal sample or test that reproduces the issue so I can troubleshoot further?

[jigneshshukla]

@jigneshshukla I'm not seeing the issue you are having.

The Map of jwtDecoders is keyed by clientRegistration.getRegistrationId(), which means each ClientRegistration has it's own JwtDecoder instance.

A custom jwsAlgorithmResolver would receive a ClientRegistration and it should return the JwsAlgorithm that is expected to be used by the provider for the the ID Token signature. The key word to note is expected, because when a client is registered with a provider, part of it's registration metadata is id_token_signed_response_alg. Therefore, if the custom jwsAlgorithmResolver is configured correctly then there shouldn't be any issues with ID Token signature verification.

Can you provide more details or a minimal sample or test that reproduces the issue so I can troubleshoot further?

@jgrandja - I agree with what you are saying and it is working as expected in the scenarios where IDP is using only one algorithm to sign ID Token. However, as per OpenID Spec (https://openid.net/specs/openid-connect-discovery-1_0.html), IDP can use more than one algorithm to sign tokens which can be indicated by id_token_encryption_alg_values_supported field from .well-known endpoint. Our IDP is doing the same. (screenshot attached for your reference).

So technically, IDP can use either of these algorithms to sign the token.

With current implementation of OidcIdTokenDecoderFactory, it's not possible to supply (through jwsAlgorithmResolver or any other means) both the algorithms to be used by underlying NimbusJwtDecoder.

I'll try to create a minimal sample to test and reproduce and will attached the details to this ticket but hopefully, with the info. I specified above and the screenshot I've attached from our IDP's .well-known endpoint, it will be helpful to understand the issue.

[jgrandja]

@jigneshshukla I understand that the provider supports RS256 and ES256, however, an ID Token can only be signed by one algorithm for a client. For example, if client-A expects RS256 and client-B expects ES256, then the logic within the custom jwsAlgorithmResolver can be implemented based on this.

[jigneshshukla]

@jgrandja - in our case, IDP is alternating between RS256 and ES256 per request from same client. Initially, when we saw the issue, my first thought was: "Does OpenID spec says anywhere that only one algorithm needs to be used for signing ID token for given client" and so tried to look into the spec, but couldn't clearly get anywhere such mention. Rather, I did find that id_token_signing_alg_values_supported is an Array so technically, it can have more than one algorithms. Based on that, I felt to open this issue.

[jgrandja]

That is unusual because as mentioned in this comment the id_token_signed_response_alg should be configured as part of the client registration and should not be signed by another algorithm during the flow. It seems to me the provider has implemented off-spec. Can you please let me know which provider you are using?

[jgrandja]

@jigneshshukla

I did find that id_token_signing_alg_values_supported is an Array so technically, it can have more than one algorithms

id_token_signing_alg_values_supported is not the same as id_token_signed_response_alg