-1

I have setup OKTA with my angular 13 application and trying to use the OKTA "tokens" api to get the authorisation token. It works perfectly fine in POSTMAN but fails with the following error on Chrome;

error: "invalid_client" error_description: "Browser requests to the token endpoint must use Proof Key for Code Exchange."

As per https://support.okta.com/help/s/article/Browser-requests-to-the-token-endpoint-must-use-Proof-Key-for-Code-Exchange?language=en_US

looks like the browser is adding "Origin" header is present in the request to the /token endpoint of the authorisation server which is causing the problem. How to fix this? I am calling the api from my local ( http://localhost:4200/ ) and the url is whitelisted. I am using "grant_type" : "client_credentials" and I believe that is causing the problem. Normal "USERS" api for OKTA works fine so not sure what I am missing.

enter image description here

Yogesh
  • 246
  • 1
  • 4
  • 20
  • The solution appears to be provided in the link you shared: The "Origin" header is used for client side requests and Okta supports only Authorization Code Flow with PKCE as client side OIDC flow on /token endpoint of the authorization server. Any other OpenID Connect flows must send the request through a server side/native method and must not have "Origin" header present. – Will Alexander Jul 05 '22 at 12:09
  • `client_credentials` flow is supposed to be used by back-end hosts, so you are doing something wrong here, unless you are just experimenting. If it's the case, then Will's comment above is a legit one – Philipp Grigoryev Jul 05 '22 at 12:20

1 Answers1

0

For SPAs, you should use Authorization Code + PKCE. This gets the access token you need for subsequent API calls.

This short resource might help clarify.

If you are implementing via Angular, there are great libraries to help you manage your tokens and will make sure your implementation is correct & secure. Don't roll your own implementation! In particular, check out

AlisaDuncan
  • 16
  • 2