OAuth v2 not working if client secret contains special characters

[kmontcalm]

First, this Extension is really useful. Thanks.
I'm using Firefox 76.0.1 (64-bit) with RESTer v4.1.1.

I configured two OAuth v2 profiles to secure the access of my REST calls.

• OAuth 2 flow: Client Credential
• Access Token Request Client Authentication: HTTP Basic authentication

One of the is using simple characters (Alphanumeric only) and everything works find.

• Example: AbcD3f9
  The other one, I used specials characters (such as "{}[]") and I'm unable to use if as the Authorization to use.
• Example: Ab[D3f9
  I received the following error when requesting the token:

If I created a restcall to get the token (calling the "oauth/token?grant_type=client_credentials" using the basic profile), both return me the expected results.

Error: Access token error: undefined. Description: undefined URI: undefined
Details:
Ua@moz-extension://5f6322de-5493-43b6-a07e-20f1a3cf2c20/site/scripts/bundle.js:5261:11442
Xa@moz-extension://5f6322de-5493-43b6-a07e-20f1a3cf2c20/site/scripts/bundle.js:5261:13264
Ya/</</<@moz-extension://5f6322de-5493-43b6-a07e-20f1a3cf2c20/site/scripts/bundle.js:5261:14117

Thanks to consider fixing that in the next release.

[frigus02]

Thanks for reporting. Which value contains non-alphanumeric characters? Is the client id or client secret?

There is 1 difference between the HTTP basic authentication performed in the OAuth 2 flow and in the one you manually do. In the OAuth 2 flow, client id and client secret are URL encoded before being used as username and password for the basic authentication.

(I didn't personally experience a use case for this, yet. But OAuth 2 seems to require it: https://tools.ietf.org/html/rfc6749#section-2.3.1).

This means the basic authentication send in the OAuth 2 flow is (assuming Ab[D3f9 is the client secret):

base64(client_id:Ab%5BD3f9)

If this is indeed the issue you're seeing, I can add an option to RESTer to not URL-encode these values in the OAuth 2 flow.

[kmontcalm]

Which value contains non-alphanumeric characters? The client secret.

Thanks about the tip of URL encoding the client secret.
But I'm still have an issue.

I make some tests with those passwords:

• Client: testclient
• Secret (test 1): Th1s{s@Test
• Secret (test 2): Th1s%7Bs%40Test (URL Encoded version of the test 1)

In both cases, when I tried to generate the temporary token, I got an error.

hl@moz-extension://5f6322de-5493-43b6-a07e-20f1a3cf2c20/site/scripts/bundle.js:5259:11564
fl@moz-extension://5f6322de-5493-43b6-a07e-20f1a3cf2c20/site/scripts/bundle.js:5259:13506
ml/<@moz-extension://5f6322de-5493-43b6-a07e-20f1a3cf2c20/site/scripts/bundle.js:5259:14173

[frigus02]

Oh sorry, I didn't make myself clear. When you give RESTer the client secret Ab[D3f9, it will do the URL encoding and send Ab%5BD3f9 to server. So the OAuth 2 server needs to URL decode the client secret.

You said that you get the correct result when you make a manual POST /oauth/token?grant_type=client_credentials. This makes me think your OAuth 2 server does not URL decode the client secret.

I can add an option in RESTer to support that behavior.

[frigus02]

I uploaded version 4.3.0, which has another authentication option for OAuth 2 called "HTTP Basic authentication (no encode)". This one does not URL-encode client id and secret, so it should work for you.