SUGGESTION - oAuth encoding

[martyn-fullfibre]

oAuth requires client ID and secret to be urlencoded.

When passing unencoded secrets that contain a + the current version will return a fail as a plus char can either be a space or a plus. According to the latest standards for oAuth clientID and secrets should be passed urlEncoded.

Ref: https://datatracker.ietf.org/doc/html/rfc6749#appendix-B

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Colin-b]

Hello, thanks for the report. The documentation you linked is talking about payload, the body of the request. While those credentials are sent in headers. Basic authentication (what is used in this case) is a common authentication flow, implemented by HTTPX in what I believe is the usual approach.

Before changing the values we send, I would like to make sure it is indeed a bug on the implementation based on the RFC, and not a behavior that only applies to the provider you use (If you can share more information on the auth provider, or even the documentation they themselves provides).

Thanks again

[martyn-fullfibre]

Hello, thanks for the report. The documentation you linked is talking about payload, the body of the request. While those credentials are sent in headers. Basic authentication (what is used in this case) is a common authentication flow, implemented by HTTPX in what I believe is the usual approach.

Before changing the values we send, I would like to make sure it is indeed a bug on the implementation based on the RFC, and not a behavior that only applies to the provider you use (If you can share more information on the auth provider, or even the documentation they themselves provides).

Thanks again

Sorry linked to the incorrect part previously:

https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.1

The catch is that a lot of OAuth 2.0 providers—Postman, Auth0, and the one we’re using—tend to expect you to percent‑encode any reserved chars (like +, :, @, or spaces) before Base64’ing. In our case the secret has + characters, and without encoding they get turned into spaces and the authentication fails.

Could we make this encoding behavior opt‑in (something like url_encode_auth=True), or at least highlight this gotcha in the docs for anyone whose provider needs it?

This can be tested by creating a secret containing a + on a provider. If you send unencoded will fail and if you send encoded it will pass.

Thanks,
Martyn