Bug Report: non-conformance to OAuth2 spec's header encoding when requesting tokens

Wyatt Carss

Hi there!


I'm pretty sure I found a bug/non-conformance to the OAuth2 spec in your oauth provider implementation. I upgraded a js oauth library (simple-oauth2) recently, and we started getting 'invalid_client' errors.


It turns out the header that this library (simple_oauth2) was constructing to authorize our POST to your https://oauth2.sky.blackbaud.com/token endpoint had first url-encoded our client_id and client_secrets individually, and then it base64 encoded "<url-encoded-client-id>:<url-encoded-client-secret>", and sent that. I dug around for a while in their library to find out why, and they actually have an option listed in their docs to control whether it behaves this way, or just does the base64 encoding of the client id and secret. It defaults to this double-encoded method, which they have called 'strict mode'.


They link in their docs[1] to the OAuth2 RFC[2] and say 'use non-strict mode if your oauth provider is non-conformant'. So after reading the spec again, it does seem clear that you're supposed to do both encodings, but that it's a common misconception. The blackbaud OAuth docs[3] state that they expect only the base64 encoded string, and only expect url-encoding for body params, and the endpoint does not seem to work if you do both as the spec requests.


Anyway, it seems like it could be a good idea to accept both the url-encoded and non-url-encoded versions of the base64 content, to allow for conformance and backwards-compatibility. It would have saved me an hour or two of digging today at the least, and it will likely hit other developers too if it hasn't already.


Cheers,

Wyatt


1 - https://github.com/lelylan/simple-oauth2/blob/master/API.md#options

2 - https://tools.ietf.org/html/rfc6749#section-2.3.1

3 - https://developer.blackbaud.com/skyapi/docs/authorization/common-auth-issues#requesting-tokens