Client credentials not correctly decoded in Basic Auth

[OrangeDog]

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.

However, the corresponding decoding is not applied when Basic client credentials are received.

Note that people often don't realise this slightly odd encoding is required, and blame their (conformant) client library instead.

[jgrandja]

@OrangeDog It's not clear to me if you are reporting a bug? If this is the case, can you please be more specific so I can better understand where the issue is?

[OrangeDog]

Yes, it’s a bug.

If your client id or secret has a special character in it, you cannot use it with Basic auth, because the code doesn’t decode it properly.

[jgrandja]

@OrangeDog I'm going to close this issue based on this comment.

[OrangeDog]

RFC 6749 is not superseded by RFC 7617. Indeed the whole point of this encoding is so it becomes a valid Basic Authentication header,

[jgrandja]

@OrangeDog I missed this on the first read:

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.

I'm surprised this issue hasn't come up already? I guess most client credentials don't have special characters (colon) in it. This is interesting and kind of feels like an edge case.

I'd like to test some well-known providers to see if they have implemented this decoding.

I'll reopen this and investigate shortly.

[OrangeDog]

It came up because I was using b64(random()) to generate secrets, and a client was encoding the /.

I would not be surprised if half of all clients and servers have failed to implement this.
I was implementing OAuth2 back in the draft days and don't recall this encoding.
Note as well it's not the standard URL-encoding algorithm, but a hybrid accounting for inconsistent handling of +.

I'm not necessarily expecting a fix here, but at least have the issue noted, and hopefully fixed in the core spring-security client. Although that's a tricky issue - a non-compliant client can be worked-around, but if the server is non-compliant there's nothing you can do with a compliant client. Probably it needs to be on by default, but able to be disabled on a per-server basis.