Spring Security Regression with URL encode client credentials #10018

Describe the bug This bug is described here "Regression with URL encode client credentials #10018", it was fixed in 5.5.2 but it appears again in 5.6.x https://github.com/spring-projects/spring-security/blob/5.6.0/oauth2/oauth2-client/src/main/java/org/springframework/security/oauth2/client/endpoint/OAuth2AuthorizationGrantRequestEntityUtils.java

BUG:

  String clientId = **encodeClientCredential**(clientRegistration.getClientId());
  String clientSecret = **encodeClientCredential**(clientRegistration.getClientSecret());
  headers.setBasicAuth(clientId, clientSecret);

with

       private static String encodeClientCredential(String clientCredential) {
        try {
            return **URLEncoder**.encode(clientCredential, StandardCharsets.UTF_8.toString());
        }
        catch (UnsupportedEncodingException ex) {
            // Will not happen since UTF-8 is a standard charset
            throw new IllegalArgumentException(ex);
        }
    }

FIX:

  headers.setBasicAuth(clientRegistration.getClientId(), clientRegistration.getClientSecret());

with setBasicAuth :

        String **credentialsString = username + ":" + password**;
        byte[] encodedBytes = Base64.getEncoder().encode(credentialsString.getBytes(charset));

To Reproduce Use spring boot 2.6 and oauth2 client credentials. If client Secret contains specific characters => URL encoding

Expected behavior Restores the 5.5.2 fix please

Sample

A link to a GitHub repository with a minimal, reproducible sample.

Reports that include a sample will take priority over reports that do not. At times, we may require a sample, so it is good to try and include a sample up front.

Comment From: rwinch

Thank you for getting in touch. This is not a bug in Spring Security OAuth. It is a bit hard to follow everything that happened in the thread, but I'll give you a summary:

The issue gh-10018 was a fix because the OAuth specification states that client credentials and secret should be encoded using the "application/x-www-form-urlencoded" encoding algorithm.

Given this broke quite a few users, the fix was reverted from the 5.2.x 5.3.x 5.4.x and 5.5.x but was kept for 5.6.x and forward. This is likely why you believe that it was fixed in 5.5.x (the commit was reverted and the actual fix does not appear until 5.6.x).

If you have an authorization server that is not URL encoding the client and secret it is not following the specification. You can work around that using the links on this comment.

Given the number of people using Authorization Servers that do not properly URL Encode the client id and secret, I created gh-11440 to simplify the configuration.