I ran into the following problem (again) a few days ago:
When the “Client Secret” of an OAuth2 authorization workflow contains a “+” sign, the request after the consent (/identity.server/connect/token) fails with “invalid_client”.
The request headers are:
Content-Type: application/x-www-form-urlencoded
Authorization: Basic [...base64 encoded client-id:client-secret...]
User-Agent: PostmanRuntime/7.43.0
Accept: */*
Cache-Control: no-cache
Postman-Token: 68809fb2-5678-47f5-a219-a5992c55a294
Host: [..hostname..]
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 156
When I manually encode the “+” sign to “%2B” it works!
The RFC 6749 - The OAuth 2.0 Authorization Framework states in section 2.3.1:
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. The authorization server MUST support the HTTP Basic authentication scheme for authenticating clients that were issued a client password.
and Appendix B gives the following example:
For example, the value consisting of the six Unicode code points
(1) U+0020 (SPACE), (2) U+0025 (PERCENT SIGN),
(3) U+0026 (AMPERSAND), (4) U+002B (PLUS SIGN),
(5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO SIGN) would be encoded
into the octet sequence below (using hexadecimal notation):20 25 26 2B C2 A3 E2 82 ACand then represented in the payload as:
+%25%26%2B%C2%A3%E2%82%AC
Could you please look into this matter?
Thanks!
swobi