I would be interested to know if anyone is able to use the OAuth2::Client#get_access_token_using_client_credentials method succesfully (and if so, please let me know what I’m doing wrong) or reproduce this issue?
Does TOKEN_URI_SUFFIX contain any query parameters? I could imagine the current implementation loosing or incorrectly encoding anything but the path component. Does passing the fully composed URI as token_uri work for you?
Ah, I see the difference now. OAuth2 posts the client_idand client_secret as a application/x-www-form-urlencoded body to the endpoint instead of using them for HTTP basic authentication.
The spec describes either behavior with a MAY https://tools.ietf.org/html/rfc6749#section-2.3.1 but it has a SHOULD on preferring the HTTP basic way, so we probably should default to that while still giving an option to include it in the request body for servers that don’t support HTTP basic authentication. I would say a pull request for this is welcome :)
Including the client credentials in the request-body using the two parameters is NOT RECOMMENDED and SHOULD be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes).
(my italics)
Since it says clients (not servers), and since a Crystal client will be capable of HTTP Basic authentication, my reading is that the Crystal OAuth2 library should always use HTTP Basic.
Do you agree?
This would also have the advantage that there would be no need to change the API of the OAuth2::Client.
I think it would be acceptable, but given the landscape of OAuth2 I’ve seen in the wild I would prefer still having the option I think. It should be possible to make it an optional named parameter, so no real API change unless your server is buggy and requires the current implementation :)