Brower requests to the token endpoint must be part of at least one whitelisted redirect_uri

I’m getting an unexpected 400 error when requesting a token using the authorization code flow with PKCE:

Browser requests to the token endpoint must be part of at least one whitelisted redirect_uri.

Note that this error is distinct from the common 400 regarding absolute URI whitelisted in client app settings.

Here is the login URL:

https://REDACTED/authorize?client_id=REDACTED&redirect_uri=http%3A%2F%2Flocalhost%3A3000&response_type=code&state=REDACTED&code_challenge_method=S256&scope=default&code_challenge=REDACTED

Here is the POST request:

curl 'https://REDACTED/v1/token'
  -H 'authority: REDACTED'
  -H 'accept: application/json'
  -H 'sec-fetch-dest: empty'
  -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36'
  -H 'content-type: application/x-www-form-urlencoded'
  -H 'origin: null'
  -H 'sec-fetch-site: cross-site'
  -H 'sec-fetch-mode: cors'
  -H 'referer: http://localhost:3000/?code=REDACTED&state=REDACTED'
  -H 'accept-language: en-US,en;q=0.9'
  --data 'code_verifier=REDACTED&grant_type=authorization_code&redirect_uri=http%3A%2F%2Flocalhost%3A3000&client_id=REDACTED&code=REDACTED'
  --compressed

Here is the client:

{
    "client_id": "REDACTED",
    "client_id_issued_at": 1584723536,
    "client_name": "REDACTED",
    "client_uri": null,
    "logo_uri": null,
    "redirect_uris": [
        "http://localhost:3000"
    ],
    "response_types": [
        "code"
    ],
    "grant_types": [
        "authorization_code"
    ],
    "token_endpoint_auth_method": "none",
    "application_type": "browser"
}

The redirect URI appears to be whitelisted for the client, so I’m not totally sure what’s causing this error message. I haven’t seen mention of this particular message anywhere in the forum or Okta documentation, and I’ve successfully implemented other PKCE clients using localhost before so I’m not sure what’s different in this case. Any ideas here? Thanks.

Hi @djfdev

Can you please open a support ticket with us through an email to developers@okta.com in order to further check the back-end logs for further details regarding this error? Please mention in the email the client ID used.

@djfdev were you able to find any resolution for this error?

@Prashanth @djfdev Has any of you got the solution?

For me it’s Native App (cordova based iOS development) scenario and redirect_uri is CustomURI Scheme. e.g. “myapp://callback”.

Kindly help.

Thanks!

@dragos Kindly help. I am facing similar issue.

@dragos @djfdev
I’m facing this same issue with my iOS (cordova based) app whereas it works fine with Android with the same redirect uri and client ID.
Anyone has a resolution for this error?
400 Bad Request
{
“error”: “invalid_request”,
“error_description”: “Browser requests to the token endpoint must be part of at least one whitelisted redirect_uri.”
}

Hi Liya,

Since this is Cordova app, Origin must be “file://”.
Can you please debug and confirm if your Request parameter, specifically Origin, is same in both (Android and iOS) or different?

Regarding Trusted Origin settings on Okta side, did you set anything?

Yes @Dijo , the Origin header was the issue and I got to know seeing the logs - “failure: illegal_origin_browser_request”.
iOS app was sending this header with value “file://” whereas Android didn’t. I had to use an advanced http library to remove the Origin header.
Thanks a lot for your time.

@LiyaJ I wonder if that is possible through any http library.

As described on MDN, Origin is a forbidden header, meaning that you cannot change it programatically.

Please let me know if you have any breakthrough on this. If I’ll get any solution, will let you know.

Thanks!

@Dijo I used a cordova plugin in my app called “cordova-plugin-advanced-http” to avoid the Origin header being sent in the request, if that helps.

1 Like

Hi Liya,

I have tried cordova advanced http plugin and it works like a charm.

Thank you very much for your suggestion!

We were going to raise support ticket and your suggestion has saved our lot of time.

Thanks Again!