Verify PKCE flow Access Token on Backend API

I see an example of how to verify implicit flow tokens via a resource server with samples-golang/resource-server at master · okta/samples-golang · GitHub

How do I do this with PKCE access tokens ? Can same method verification above be used or do I need to use /introspect or another solution ?

Note: This is SPA accessing backend APIs

@dsommerl Here is the doc for validate token.
Are you talking about obtain access token via PKCE flow and implicit flow?

Thanks, @Lijia just PKCE flow

Is the only advantage to remote validation if tokens are revoked ?

@dsommerl Here is the pkce flow to obtain a token

Introspection Request takes your token as a URL query parameter and returns back a simple JSON response with a boolean active property.
This may incur a network request which is slower to do verification, but can be used when you want to guarantee that the access token hasn’t been revoked.

1 Like

Hi @dsommerl! I’m a week late to the party but I wanted to add a couple of things to this thread, might be useful for you or anyone else reading it:

  1. It isn’t really mentioned clearly, but the only code that is going to revoke an access token from a custom server is the application that requested it, so you know in your architecture if tokens are revoked or not. If they are not ever revoked, then local validation in the API is preferred over using /introspect; it’s faster and doesn’t count against your rate limits.

  2. You don’t have to use Okta’s jwt-verifier, although it does a lot of the work for you :slight_smile: Some folks prefer to use other third-party tools like the jsonwebtoken package to less dependent on the identity provider tools. The jsonwebtoken package for example needs you to go find the keys, and then it only verifies the signature and the audience claim. You need to verify the issuer, the expiration date, etc. yourself. When I do it, I do it backwards from the Okta books; it’s computationally cheaper to verify the expiration date and other claims before checking the signature.

  3. If you do your own verification, don’t hardwire in the URL for the keys. Get the discovery document for your authorization server and get the URL for the keys from it. Both the OAuth and OIDC discovery documents will have the same path to the keys: OpenID Connect & OAuth 2.0 API | Okta Developer. Also, keys are rotated occasionally. If you do this locally and you don’t have the right key from your last cached read, then check again to see if a new key was issued. If you use the Okta jwt-verifier it should handle this for you.

  4. If you want an example of a SPA that doesn’t use any SDKs so you can see the flows working without anything standing between you and the IdP look at my working example: GitHub - jmussman/pirates.