Missing support for private_key_jwt in ClientRegistrations

[ThomasKasene]

Describe the bug
I'm trying to set up an OAuth2 client against https://ver2.maskinporten.no/, whose .well-known configuration endpoint looks like this:

{
  "issuer": "https://ver2.maskinporten.no/",
  "token_endpoint": "https://ver2.maskinporten.no/token",
  "jwks_uri": "https://ver2.maskinporten.no/jwk",
  "token_endpoint_auth_methods_supported": [ "private_key_jwt" ],
  "grant_types_supported": [ "urn:ietf:params:oauth:grant-type:jwt-bearer" ]
}

I figured I'd try to use the new support for private_key_jwt in Spring Security 5.5.0 (in combination with Spring Boot 2.4.5), but when I start the application I get an error:

Caused by: java.lang.IllegalArgumentException: Only ClientAuthenticationMethod.CLIENT_SECRET_BASIC, ClientAuthenticationMethod.CLIENT_SECRET_POST and ClientAuthenticationMethod.NONE are supported. The issuer "https://ver2.maskinporten.no/" returned a configuration of [private_key_jwt]
	at org.springframework.security.oauth2.client.registration.ClientRegistrations.getClientAuthenticationMethod(ClientRegistrations.java:280) ~[spring-security-oauth2-client-5.5.0.jar:5.5.0]
	at org.springframework.security.oauth2.client.registration.ClientRegistrations.withProviderConfiguration(ClientRegistrations.java:243) ~[spring-security-oauth2-client-5.5.0.jar:5.5.0]
	at org.springframework.security.oauth2.client.registration.ClientRegistrations.lambda$getRfc8414Builder$1(ClientRegistrations.java:190) ~[spring-security-oauth2-client-5.5.0.jar:5.5.0]
	at org.springframework.security.oauth2.client.registration.ClientRegistrations.getBuilder(ClientRegistrations.java:209) ~[spring-security-oauth2-client-5.5.0.jar:5.5.0]
	at org.springframework.security.oauth2.client.registration.ClientRegistrations.fromIssuerLocation(ClientRegistrations.java:145) ~[spring-security-oauth2-client-5.5.0.jar:5.5.0]
	at org.springframework.boot.autoconfigure.security.oauth2.client.OAuth2ClientPropertiesRegistrationAdapter.getBuilderFromIssuerIfPossible(OAuth2ClientPropertiesRegistrationAdapter.java:83) ~[spring-boot-autoconfigure-2.4.5.jar:2.4.5]
	at org.springframework.boot.autoconfigure.security.oauth2.client.OAuth2ClientPropertiesRegistrationAdapter.getClientRegistration(OAuth2ClientPropertiesRegistrationAdapter.java:59) ~[spring-boot-autoconfigure-2.4.5.jar:2.4.5]
	at org.springframework.boot.autoconfigure.security.oauth2.client.OAuth2ClientPropertiesRegistrationAdapter.lambda$getClientRegistrations$0(OAuth2ClientPropertiesRegistrationAdapter.java:53) ~[spring-boot-autoconfigure-2.4.5.jar:2.4.5]
	at java.base/java.util.HashMap.forEach(HashMap.java:1336) ~[na:na]
	at org.springframework.boot.autoconfigure.security.oauth2.client.OAuth2ClientPropertiesRegistrationAdapter.getClientRegistrations(OAuth2ClientPropertiesRegistrationAdapter.java:52) ~[spring-boot-autoconfigure-2.4.5.jar:2.4.5]
	at org.springframework.boot.autoconfigure.security.oauth2.client.servlet.OAuth2ClientRegistrationRepositoryConfiguration.clientRegistrationRepository(OAuth2ClientRegistrationRepositoryConfiguration.java:49) ~[spring-boot-autoconfigure-2.4.5.jar:2.4.5]
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:na]
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
	at java.base/java.lang.reflect.Method.invoke(Method.java:566) ~[na:na]
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) ~[spring-beans-5.3.6.jar:5.3.6]
	... 83 common frames omitted

To Reproduce
I try the following configuration in my application.yml, just to get off the ground:

spring:
  security.oauth2.client:
    provider:
      maskinporten.issuer-uri: https://ver2.maskinporten.no/
    registration:
      maskinporten-private-key-jwt:
        client-id: 1337
        provider: maskinporten
        scope: test:test

Expected behavior
I expected this part of the client setup to work "out of the box", but there appears to be something missing from org.springframework.security.oauth2.client.registration.ClientRegistrations.getClientAuthenticationMethod, maybe? Unless I'm not supposed to have reached that code path at all, in which case I don't know what to expect.

Sample
I put together a small, reproducible sample which uses Maven, hopefully that's okay.

[anoopgarlapati]

@ThomasKasene It seems you are missing client-authentication-method: private_key_jwt property. Can you please try adding this property to your sample and validate.
There are good set of instructions in the Spring Security reference guide for client authentication using private_key_jwt.

[ThomasKasene]

I already tried with both client-authentication-method: private_key_jwt and authorization-grant-type: urn:ietf:params:oauth:grant-type:jwt-bearer but the result is the same. This happens when the application is trying to parse the result from the .well-known configuration endpoint, and it's encountering some hardcoded limits, if I understand it correctly.

(By the way, isn't the client registration smart enough to auto-configure itself with the client-authentication-method and the authorization-grant-type it gets from the .well-known endpoint, just like it does with the issuer-uri and jwk-set-uri?)

[jgrandja]

Related gh-9795

[jgrandja]

Thanks for reporting this bug @ThomasKasene.

In the meantime, you could workaround this by not configuring the issuer-uri property and instead explicitly configuring all the required ClientRegistration properties, e.g. token-uri, etc.

Also, could you please log a separate ticket for the issue related to authorization-grant-type.

[ThomasKasene]

One way to do that is to override the ClientRegistrationRepository bean definition that Spring Boot creates? Something along the lines of:

    @Bean
    InMemoryClientRegistrationRepository clientRegistrationRepository(OAuth2ClientProperties properties) {

        Collection<ClientRegistration> propertyBackedClientRegistrations = OAuth2ClientPropertiesRegistrationAdapter
                .getClientRegistrations(properties).values();

        ClientRegistration maskinportenClientRegistration = ClientRegistration
                .withRegistrationId("maskinporten-private-key-jwt")
                .clientAuthenticationMethod(ClientAuthenticationMethod.PRIVATE_KEY_JWT)
                .authorizationGrantType(AuthorizationGrantType.JWT_BEARER)
                .scope("test:test")
                .tokenUri("https://ver2.maskinporten.no/token")
                .clientId("1337")
                .clientName("Maskinporten")
                .build();

        List<ClientRegistration> registrations = new ArrayList<>(propertyBackedClientRegistrations.size() + 1);
        registrations.addAll(propertyBackedClientRegistrations);
        registrations.add(maskinportenClientRegistration);

        return new InMemoryClientRegistrationRepository(registrations);
    }

I'm not sure what you mean by "the issue related to authorization-grant-type" though? If there's more trouble ahead with the property/discovery URL-based configuration, I don't know about it yet, as I haven't gotten past this first issue.

[jgrandja]

@ThomasKasene

One way to do that is to override the ClientRegistrationRepository bean definition

Yes that is one way, but the way I suggested is to simply define the Boot properties without defining issuer-uri. You would need to define the token-uri property within the provider properties.

I'm not sure what you mean by "the issue related to authorization-grant-type"

Regarding your comment:

I already tried with both client-authentication-method: private_key_jwt and authorization-grant-type: urn:ietf:params:oauth:grant-type:jwt-bearer but the result is the same.

Looks like only authorization_code is allowed else an error is thrown here as well.

[cortex93]

(By the way, isn't the client registration smart enough to auto-configure itself with the client-authentication-method and the authorization-grant-type it gets from the .well-known endpoint, just like it does with the issuer-uri and jwk-set-uri?)

No, issuer metadata exposes what the authorization server support not what a client must use. Client will use the metadata depending on what grant type and client authentication method they want to use.

On the other hand, it would be possible to check upfront that the client configuration will eventually fail to request a token due to unsupported configuration but I'm not convince it worth it. I haven't seen any client implementation doing that kind of check. metadata is often only used to get endpoint uri.

I already tried with both client-authentication-method: private_key_jwt and authorization-grant-type: urn:ietf:params:oauth:grant-type:jwt-bearer but the result is the same.

Looks like only authorization_code is allowed else an error is thrown here as well.

It works for me with jwt-bearer grant type and a custom grant type. I use JWK keys.
Configuration may be simpler by avoiding to redefine each Token Response Client. Just declaring a JWK resolver should be sufficient to activate the feature for all grant type.