Client credentials not correctly encoded in Basic Auth

[DrZ7]

Summary
OAuth2AuthorizationGrantRequestEntityUtils.getTokenRequestHeaders does not work properly if client credentials contain special characters. From RFC 6749:

Clients in possession of a client password MAY use the HTTP Basic
authentication scheme as defined in [RFC2617] to authenticate with
the authorization server. The client identifier is encoded using the
"application/x-www-form-urlencoded" encoding algorithm per
Appendix B, and the encoded value is used as the username; the client
password is encoded using the same algorithm and used as the
password.

Actual Behavior
The client with client name or password containing special characters cannot login. The provider returns exception.

Expected Behavior
The client with client name or password containing special characters can be authenticated.

Configuration Sample
spring.security.oauth2.client.registration.sth.client-secret = sthUI=+2~fubar

Where
org.springframework.security.oauth2.client.endpoint.OAuth2AuthorizationGrantRequestEntityUtils.getTokenRequestHeaders(ClientRegistration)

Related
This is related to spring-attic/spring-security-oauth#1826

[eleftherias]

Thanks for reaching out @DrZ7.
Which provider are you using when you see the exception?
Could you also share the stacktrace here?

[DrZ7]

This ticket is the counterpart to spring-attic/spring-security-oauth#1826...
Our provider works according to specification, it decodes client name and password.
Replacing
headers.setBasicAuth(clientRegistration.getClientId(), clientRegistration.getClientSecret());
with
headers.setBasicAuth(URLEncoder.encode(clientRegistration.getClientId(), StandardCharsets.UTF_8), URLEncoder.encode(clientRegistration.getClientSecret(), StandardCharsets.UTF_8));
fixes the issue...

stack with special character password and without encoding:

org.springframework.security.oauth2.client.ClientAuthorizationException: [invalid_token_response] An error occurred while attempting to retrieve the OAuth 2.0 Access Token Response: 401 : [no body]
at org.springframework.security.oauth2.client.ClientCredentialsOAuth2AuthorizedClientProvider.getTokenResponse(ClientCredentialsOAuth2AuthorizedClientProvider.java:96)
at org.springframework.security.oauth2.client.ClientCredentialsOAuth2AuthorizedClientProvider.authorize(ClientCredentialsOAuth2AuthorizedClientProvider.java:85)
at org.springframework.security.oauth2.client.DelegatingOAuth2AuthorizedClientProvider.authorize(DelegatingOAuth2AuthorizedClientProvider.java:71)
at org.springframework.security.oauth2.client.AuthorizedClientServiceOAuth2AuthorizedClientManager.authorize(AuthorizedClientServiceOAuth2AuthorizedClientManager.java:142)

[jzheaux]

I believe this can be addressed by supplying a custom headers converter:

@Bean
public OAuth2AuthorizedClientManager authorizedClientManager(
    ClientRegistrationRepository registrations,
    OAuth2AuthorizedClientRepository clients) {
  Converter<OAuth2ClientCredentialsGrantRequest, HttpHeaders> headersConverter = (request) -> {
      ClientRegistration registration = request.getClientRegistration();
      HttpHeaders headers = new HttpHeaders();
      headers.setAccept(Collections.singletonList(MediaType.APPLICATION_JSON));
      headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED);
      headers.setBasicAuth(
          URLEncoder.encode(registration.getClientId(), StandardCharsets.UTF_8), 
          URLEncoder.encode(registration.getClientSecret(), StandardCharsets.UTF_8));
      return headers;
  };
  OAuth2ClientCredentialsGrantRequestEntityConverter entityConverter =
      new OAuth2ClientCredentialsGrantRequestEntityConverter();
  entityConverter.setHeadersConverter(headersConverter);
  DefaultClientCredentialsTokenResponseClient client = 
      new DefaultClientCredentialsTokenResponseClient();
  client.setRequestEntityConverter(entityConverter);
  OAuth2AuthorizedClientProvider authorizedClientProvider = 
      OAuth2AuthorizedClientProviderBuilder.builder()
          .clientCredentials((clientCredentials) -> clientCredentials
              .accessTokenResponseClient(client))
          .build();
  DefaultOAuth2AuthorizedClientManager authorizedClientManager =
      new DefaultOAuth2AuthorizedClientManager(registrations, clients);
  authorizedClientManager.setAuthorizedClientProvider(authorizedClientProvider);
  return authorizedClientManager;
}

Perhaps @jgrandja can provide a simpler configuration.

The spec does seem to indicate that URL encoding should be performed by default. If so, then applications using a non-compliant provider would need to provide a headers converter instead. @jgrandja do you think the default client behavior should change?

This question has cropped up on the authorization server side of things in a couple of different places recently.

[jgrandja]

@DrZ7 The configuration that @jzheaux provided is correct and will work for the compliant provider you are using. I'm assuming you already applied a similar custom configuration and it's working?

I agree that OAuth2AuthorizationGrantRequestEntityUtils.getTokenRequestHeaders() should be updated to comply with the spec, but as @OrangeDog mentioned in this comment, applying the fix now may break existing applications that are using non-compliant providers.

Therefore, I've scheduled this fix for Spring Security 6.0 (Update: Spring Security 5.6).

[DrZ7]

At the moment we are using our own OAuth2ClientCredentialsGrantRequestEntityConverter b/c setHeadersConverter is not yet available.

[jgrandja]

@DrZ7 Regarding my last comment:

applying the fix now may break existing applications that are using non-compliant providers. Therefore, I've scheduled this fix for Spring Security 6.0.

We're going to apply this fix in 5.5 since this is a bug. We'll come up with a strategy that does not break existing applications.

[AT92]

Hello together,
had the same issue with spring-security-oauth2-client-5.6.0 again.
After downgrading to 5.5.3 the problem was resolved, so I think the bug came again with new release.

[sjohnr]

had the same issue with spring-security-oauth2-client-5.6.0 again.

Hi @AT92. Can you describe what you mean by this? Are you saying it did not encode correctly, or it is now encoding and you don't want it to?

[rynoj]

Hi, we're facing the same. After updating to 5.6.0 credentials are being encoded again and we don't want it to (since the do contain some special characters)

[sjohnr]

@rynoj that is correct. See this comment on #10018. This change is permanent starting with 5.6. See this comment if you need help working around the issue with a non-compliant provider.

Also note that if you're using reactive, we've merged a change for #10130 which simplifies customizing headers beyond what the stackoverflow post linked above demonstrates.

[rynoj]

Ah thanks @sjohnr missed those comments! I'll have a look at the provided workarounds.