I’m using okta-vue in our app for the authorization flow which works fine, but when I try to verfify a sent id-token in the backend with jwt-verifier, I can’t verify the nonce value because it’s a random value, but required for verification.
Am I using the wrong flow or can I set the nonce value somehow? I can set the nonce value in okta-auth-js on the token.getWithRedirect function request, but since this is handle by the okta-vue guard, I cannot set this directly and there is no option when initializing okta-auth.
What would be the best way to handle this problem?
Why is your backend validating an ID token? If you are trying to protect an API/resource server with OAuth tokens, you should be using Access Tokens instead for auth. ID tokens should only be used as proof of user authentication and to get user details. Access Tokens are used for authorization use cases. I like this article that Auth0 has about the difference.
As I understood jwt-verifier is a library that is used to verify access-tokens.
The backend is validating an id-token because the /v1/keys endpoint is only giving back id-token public keys and no keys for access-tokens.
From the okta docu: “Therefore, Okta by design does not provide the public keys used to sign these access tokens.”
I’m confused now.
And yes, the okta-vue uses okta-auth-js, but is not providing an option to set the nonce value via options object. How to I tell the okta-auth-js behind okta-vue which nonce value to use?
If the kid in the Access Token doesn’t match one listed at the JWKs endpoint, then you are most likely using the Org Authorization Server, which is only supported to be used in OIDC (authentication) use case and not OAuth (Authorization) use cases. More details here: Signature Validation Failed on Access Token | Okta Help Center
If you need to validate an Access Token, a custom Authorization Server should be used. If you do not have sufficient licensing in your Okta org to use custom authorization servers, you could look to use the /introspect endpoint to check for token validity, but again, the Org Authorization Server is not designed to support this use case