ClientSecretBasic incorrectly URL-encodes client IDs and secrets

[Pétur Runólfsson]

The ClientSecretBasic class URL-encodes the client ID and secret before forming the Authorization header, and URL-decodes both values when parsing the header. This doesn't seem to be correct - there is no mention of URL-encoding in RFC 2617 section 2, and the header value produced by the ClientSecretBasic class for the example given in the RFC differs from the value provided in the RFC.

ClientSecretBasic: QWxhZGRpbjpvcGVuK3Nlc2FtZQ==

RFC 2617: QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Here's a test that reproduces the problem:

public class ClientSecretBasicTest {

  @Test
  public void testEncodeExample() {
    // Example from http://tools.ietf.org/html/rfc2617#section-2
    ClientSecretBasic secret = new ClientSecretBasic(new ClientID("Aladdin"), new Secret("open sesame"));
    assertEquals("Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==", secret.toHTTPAuthorizationHeader());
  }

  @Test
  public void testDecode() throws ParseException {
    ClientSecretBasic secret = ClientSecretBasic.parse("Basic YStiOmMrZA==");
    assertEquals(new ClientID("a+b"), secret.getClientID());
    assertEquals("c+d", secret.getClientSecret().getValue());
  }
}

[Connect2id OSS]

This is not the first time we get this reported :)

The OAuth 2.0 spec requires the client ID and secret to be encoded with "application/x-www-form-urlencoded" before passing them to the HTTP basic auth [1] algorithm. This is done to prevent unexpected behaviour when special characters are fed into the auth algorithm. Unfortunately, the original HTTP Basic Auth spec (RFC 2617) does not foresee this, and the library that you're probably using does not either.

[1] http://tools.ietf.org/html/rfc6749#section-2.3.1

[Connect2id OSS]

Thanks for spotting this, we'll update the example to show the expected encoding.

It also makes sense to add a note about the URL-encoding.

[Connect2id OSS]

Updated docs and example in commit b26ee94.