Encoding client_id and client_secret correctly

Encoding the client_id and client_secret for the HTTP Basic authentication scheme can be tricky, especially when these values contain special characters such as spaces (' ') or colons (':'). Incorrect encoding may lead to authentication failures. Admittedly, over the years, we have had to update Identify to correctly handle encoded data sent from clients.

According to https://www.rfc-editor.org/rfc/rfc6749.html#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.

Here is an example that demonstrates the correct encoding process:

• Client ID: my:client id
• Client Secret: p@ss:word!

Step 1: URL-encode both values (per application/x-www-form-urlencoded rules)

Input	Encoded Value
my:client id	my%3Aclient+id
p@ss:word!	p%40ss%3Aword%21

Note: : becomes %3A, ' ' becomes +, @ becomes %40, ! becomes %21

Step 2: Concatenate the encoded values with a colon (:)

my%3Aclient+id:p%40ss%3Aword%21

Step 3: Base64-encode the result

Base64("my%3Aclient+id:p%40ss%3Aword%21") = bXklM0FjbGllbnQraWQ6cCU0MHNzJTNBd29yZCUyMQ==

Step 4: Send in an HTTP request header

Authorization: Basic bXklM0FjbGllbnQraWQ6cCU0MHNzJTNBd29yZCUyMQ==

Decoding flexibility

While the official encoding method converts a space (' ') to a +, Identify's decoding method is flexible and will interpret both + and %20 as a space when decoding the authorization header.