Invalid signature in Access and Id Token

[mgremont]

Hello,

I’m a beginner with Okta and with application authorization workflow in general so I apologize if my questions seem dumb.

I am currently building an Angular 4 web application that call Rest APIs made with Loopback (a Node.js API Framework) to access data.

To secure my web application access i’m using the Okta authentication with Open ID Connect (oidc) the application configured as an SPA on Okta.

This part works fine but when I try to validate Access Token or Id Token on server side (using @okta/jwt-verifier) I get the following error:
''Error while resolving signing key for kid “QuchAjn_-2c-jpEdGNdhf7s3s8KUQrZMdwCG77WZf0I”

If I use jwt validation websites like jwt or jsonwebtoken (sites are in .io but I can’t post more than 2 links per messages) I get the same error when I paste my tokens: Invalid Signature (but I can retrieve all other informations contained in the token)

On client side i’m using angular-oauth2-oidc to manage the user authentication to Okta and retrieve Access and Id tokens. On server side, to secure API endpoints, i’m using @okta/jwt-verifier with the default Authorization server as issuer and the client id of my application.

I saw on this topic that we can see our authorization server keys with the following endpoints ‘[my okta org].com/oauth2/default/v1/keys’, but there were no key with the kid I have in my Access or Id Token. Is it normal?

I also tried to create a custom authorization server but I’m a bit lost between the configuration of my client application in ‘Applications’ section of Okta and the configuration of the custom authorization server, especialy the role of each one and the interaction between them.

I hope i’m clear enough and tell me if it’s not the case.

Thank you very much for your help,

[tom]

No such thing as a dumb question, and I’m glad you saw the existing thread on this. I have a feeling you aren’t using the right authorization server (issuer of the token).

When you say you are using Okta Authenitcation, are you using a library or widget?
If you are inspecting your JWT, what does the iss claim say (does it end with /oauth2/default)?
Can you share your configuration in the SPA?

Thanks,
Tom

[vijet]

It seems like the access_token you got back from the authorization server is being signed by a different key, than what is expected by the jwt-verifier library.

I would suggest you to check the following things -

1. Check the “issuer” URL you have set in the client side application (angular-oauth2-oidc configuration)
   It should be in the form of https://{yourOktaDomain}.com/oauth2/default

2. Ensure that the issuer url in server side is also set to the same.
   E.g
   const oktaJwtVerifier = new OktaJwtVerifier({ issuer: 'https://{yourOktaDomain}.com/oauth2/default', assertClaims: { aud: 'api://default', }, });

If you still get the same error,
check the key ids in the jwks_uri of your default authorization server - https://{yourOktaDomain}.com/oauth2/default/v1/keys
This is an endpoint that exposes the public key information that is used in token signing
It’ll be something like this -

Note down the property “kid” (key-id) in particular in the output from the above endpoint. (There could be multiple keys, hence multiple kids)

Now, check if any of the kids the above endpoint, is the same kid you got in the error.
E.g. in your error message, the kid is "QuchAjn_-2c-jpEdGNdhf7s3s8KUQrZMdwCG77WZf0I"
Check if that kid is listed in the json output obtained from keys endpoint.

I’m guessing the issue here is that the “issuer” url is not set correctly, which is why you’re getting this error.

Also, in the “jwt verifier”.io websites, you will get the “invalid signature” because they can’t retrieve the public key needed to validate the signature of the jwt. You need to paste the public key in order to get signature validation. I wouldn’t worry about that.

Hope this helps.

[mgremont]

Thank you both for your explanations, it helped me to solve my problem but i’m not sure I’m on the right Authorization Server.

@vijet You were right, I had a misconfiguration server side, for a working authentication I had to use the IdToken and not the access_token then change the configuration as following:

Client Side Issuer: ‘https://{myOktaDomain}.com’
Server Side Issuer: ‘https://{myOktaDomain}.com/oauth2/’
Server Side Audience: My Client Side app clientId

If I try to use https://{myOktaDomain}.com/oauth2/default as issuer client side, i’m not redirected to the Okta login page and I get an angular-oauth2-oidc uncaught error.

Maybe it’s due to my app configuration in Okta (See screenshots of my configuration at the end of the post)

@tom When I say that i’m using the Okta authentification on the client side I mean that I use the package angular-oauth2-oidc who redirect to the default Okta login page on login then get back app on success via the redirect uri. (I don’t use on okta widget or custom login form on my web app).

The issuer for my access token and my Id token is: https://{myOktaDomain}.com
For the Id Token the audience is my ap clientId and for the Access Token it is the same url as the issuer.

Thank you again.!

[tom]

Thanks for this information, I still need to draw a couple lines here, but I think I see what has happened. If I’m incorrect let me know.

I think your org is an IT Product SKU or you are on an IT Product Trial that was created before 2017-07. Okta did some heavy surgery and some product modifications so we could have a better onboarding experience for API Access Management (The part of the product that provides OAuth 2.0). Unfortunately, there wasn’t a good way for Okta to move existing customers over to the new model (with the default authorization server) without breaking backward compatibility. This is probably way too much information, but I just wanted to let you know what is going on.

For you, in particular, you need to get the issuer for your API Access Managment authorization server, which can be found in Security -> API -> Authorization Servers:

That is the issuer you should use on both your client and server.

The current issuer for your ID Token and Access Token is using the Okta Org Authorization Server, which will generate an Access Token that can’t be validated by your server (it is meant for the Okta API endpoints).

Let me know if this is correct and if this resolves this for you.

Thanks,
Tom

[mgremont]

You’re right, the org was created before 2017-07 and you found the problem.
Using a custom Authorization Server fixed it, now both the validation for Access Token and Id Token works.
Thank you very much!

[ce_ryan]

Thank you! This is what worked for me as well.

Since I am on an enterprise account I do not have the Authorization Server settings found in most documentation.

Client Side Issuer: ‘https://{myOktaDomain}.com’
Server Side Issuer: ‘https://{myOktaDomain}.com/oauth2/’
Server Side Audience: My Client Side app clientId

And also use the id_token instead of access_token.