Add a SignatureAlgorithm value to support the 'none' alg type.

[bjconlan]

Summary

While inherently noted as bad practice (https://connect2id.com/products/nimbus-jose-jwt/vulnerabilities), the 'none' Jwk Algorithm sent by an authentication server should be supported as a SignatureAlgorithm. (This seems to be the case often in poorly configured or older ping federate/ping identity servers)

Currently there is no way to use the NimbusJwtDecoder builder class support this mechanism without implementing a JwtDecoder.

Actual Behavior

Currently only the limited subset of defined enumerable values is supported by the SignatureAlgorithm

Expected Behavior

a) A 'NONE' value is added to the SignatureAlgorithm enum.

b) NimbusJwtDecoder provides overloaded mechanisms for setting the jwsAlgorithm(s) which are inline with those supported by nimbus JOSE (or simply strings)

c) An explicit builder method on the NimbusJwtDecoder is provided to use 'none' as a supported jwsAlgorithm

Version

spring-security-oauth2-jose:5.2.1

Sample

...
  @Bean
  public JwtDecoder jwtDecoder(final ClientRegistrationRepository clientRegistrationRepository) {
    final ClientRegistration.ProviderDetails oauthProvider =
        clientRegistrationRepository.findByRegistrationId(securityProvider).getProviderDetails();
    return NimbusJwtDecoder
        .withJwkSetUri(oauthProvider.getJwkSetUri())
        .jwsAlgorithms(() -> Set.of(SignatureAlgorithm.RS256, SignatureAlgorithm.NONE))
        .build();
  }
...

[bjconlan]

This could perhaps fall under #7269

[bjconlan]

Actually after tracing the codepath this looks to just be a case of our auth servers being poorly implemented or setup. There shouldn't be a need for this if explicitly using signed jwt tokens (and falling back to plain tokens identifies something is incorrect when using JWK's. Closing.