OIDC PKCE flow for client API auth - best option?


Apologies If I’m not succinct with my question - this is all new to me. I have read a great deal from the Okta docs including creating signed JWTs, the PKCE flow for single page (in my case, multi-page with a limited backend server for the API).

As I said, we have a web UI served with a bunch of static html, CSS and JS to the client. This then uses a separate API to access resources about the current application state, etc.

The backend server accepts a signed JWT token passed on the Authorization header. The key is stored in a .yml file within the container. It uses this to authorize the user on each API call, and limits access to resources based on user info. Importantly, the user can be signed in or out here. The only things that change are the responses from the API.

Firstly, This Guide indicates to me that the option to go down is the pkce flow, whereby:

  1. User visits site & hits login button
  2. JS runs client side and generates a hashed code verifier
  3. Redicrects to Okta with hashed code verifier as query parameter
  4. User authenticates
  5. Okta redirects back to site alongside authorization code
  6. Client requests tokens using authorization code + unhashed code verifier
  7. Okta verifies by hashing + comparing then returns tokens

Now my client side has the bearer tokens, including the id_token.

Can I provide a key to Okta to hash this id_token before returning it, for my server to then verify the id_token information before returning the API response?

If I am correct, then do I need to register my app as a ‘Web App’ rather than a ‘Single Page App’, as this allows self-signing of the JWT id_token, and I am technically authorizing on the server side rather than the client side?


Hey Patrick,

Thankyou for this answer. It is immensely helpful and I am very appreciative for the detailed response.

It seems like the PKCE flow for authentication with Okta is suitable for your multi-page application. However, rather than having Okta hash the id_token before returning it, it’s more typical for Okta to handle token signing, and your server verifies tokens using Okta’s public keys. Considering your server-side authorization approach, registering your app as a ‘Web App’ instead of a ‘Single Page App’ in Okta might align better with your requirements. This allows for more secure server-side authentication and authorization processes.