Fix encoding of client id and secret in HTTP Basic

[p2004a]

Per https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.1 the parameters first need to be url encoded.

[evert]

Definitely missed that! Thank you

[panva]

This implementation is unfortunately not correct.

Please see a reference of how it could be done properly.

[p2004a]

I will open next PR to make it fully compliant.

[evert]

Reading the appendix, I fail to see what's wrong (but might be missing something) the implementation you shared encodes space as + and encodes more characters than encodeURIComponent, but that doesn't mean it's incorrect for x-www-form-urlencoded.

I'd love to see a source that supports this requirement, I just don't get that from the appendix alone. (it also feels a bit silly, only non-ascii and : really matters in this context). Without a stronger source, I rather stick with the implementation from this PR. Less is more!

[evert]

I appreciate the flag though @panva !

[p2004a]

AFAIU the scheme of encoding as defined in the spec is fully deterministic, so I can imagine a hypothetical case of the authorization server doing a string comparison on encoded, not decoded values.

[evert]

It feels a tad theoretical, but would new URLSearchParams({v: input}).toString().slice(2) work?

[panva]

Out of the alphabet that needs escaping encodeURIComponent omits escaping - _ . ! ~ * ' ( ) and it uses %20 instead of + for (U20 SPACE).

Using encodeURIComponent produces incomplete and in the case of space also incorrect, x-www-form-urlencoded encoding.

[p2004a]

This is a mess IMHO...

The primary difference is that https://datatracker.ietf.org/doc/html/rfc6749#appendix-B explicitly says

the "application/x-www-form-urlencoded" media type was defined in Section 17.13.4 of [W3C.REC-html401-19991224]

which says (emphasis mine):

Control names and values are escaped. Space characters are replaced by '+', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by '%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., '%0D%0A').

Now, things like URLSearchParams percent-encode anything in the application/x-www-form-urlencoded percent-encode set as defined by living spec which also allows * - . _ to be not encoded.

So, effectively, to be the most strict interpretation requires encoding everything non-alphanumeric (and special treatment of space...)

[panva]

Yes it is a mess, which is why we're switching from

OAuth 2.0 Basic (MUST support) and Body (MAY, NOT RECOMMENDED)

to

OAuth 2.1 Body (MUST support) and Basic (MAY, NOT RECOMMENDED)

oauth-wg/oauth-v2-1#128