Hi all,
I’m trying to understand how I can verify token signature.
I was looking for some public key in jwks_uri, but there is nothing. It’s my link https://dev-906776.oktapreview.com/oauth2/ausebi0hs5liZf6FC0h7/v1/keys
Please say, how can I make sure that my token isn’t falsified.
Okta uses asymmetric (RS-256) signatures for tokens. That link is a JSON Web Key Set (JWKS). It is actually an RSA public key 
You can retrieve this key information in your code and use it to verify a token signature.
Most languages and frameworks have libraries that can verify asymmetric signatures this way. What language are you working in?
1 Like
Thanks for your reply.
I think I’ve understood it. If I’m wrong, please correct me.
JWKS link contains modulus and exponent(“e” and “n” fields), which is employed to generate public key certificate.
Then it will be used to decrypt the signature.
My future task is the Okta API development in Golang. But I was never working with Okta.
Yes, the JWK Set contains one or more keys. As you said, those fields (e and n) can be used to reconstruct the RSA key. In this case it’s not used for decryption, but to verify the signature hash. You can read about the JWKS format in the JWKS spec.
We are currently working on some Golang tools including a JWT verifier library. It’s not done yet but it should make this easier in Go when we publish it on Github. 
@nate.barbettini when will the golang JWT verifier library be available? Pending its availability what are the other methods to verify the token in Golang Code?
Hi @prasadj,
We already have the golang JWT verifier in beta - https://github.com/okta/okta-jwt-verifier-golang
We also have a golang sample application that uses the JWT verifier which you can use as reference - https://github.com/okta/samples-golang/tree/develop/resource-server
Let us know if this is helpful.
@vijet @nate.barbettini I am getting an error validating a token. Im using the above library. This is the error im seeing.
could not decode token: failed to verify with any of the keys
The token is
eyJraWQiOiJwZmJwU1ctenNZYnRTalJLSUdVRVZuOEd0dzNlNVhuZWlSZS1sUGJUajFJIiwiYWxnIjoiUlMyNTYifQ.eyJ2ZXIiOjEsImp0aSI6IkFULndycmhPaVd6cVlEV04yWnNIZEtadDc1enJBYVl6WG5NVURZazZLT0otTnciLCJpc3MiOiJodHRwczovL251dGFuaXhkZXYub2t0YXByZXZpZXcuY29tIiwiYXVkIjoiaHR0cHM6Ly9udXRhbml4ZGV2Lm9rdGFwcmV2aWV3LmNvbSIsInN1YiI6InByYXNhZC5qYWtrYUBudXRhbml4LmNvbSIsImlhdCI6MTUyNTQ3MjM1NCwiZXhwIjoxNTI1NDc1OTU0LCJjaWQiOiIwb2FldzB0MmZzenlaSXU0RTBoNyIsInVpZCI6IjAwdWV2c3llMXZKWjZ0MDg5MGg3Iiwic2NwIjpbInByb2ZpbGUiLCJvcGVuaWQiXX0.Oztp04S6mw6vaoc57poMcdPrLqchGGm036UPo0n2HYFbW4akWDb9YQ5-1xYxtFtkyVpCBPm_Lfph_9NzfErWrG4_aTSuhM-73WykeaHykuXpfOWBjmIh7YZeVS-opxGYjyN51BxJ5-0NtVPiPuAnmbyzQHj-5lsgdTPenRxPpsCCCFI2K_tnzw2IQeNlz-Y4ALk5OL4i7GRwJF-KIl_YJKzOt9VQdeZ1xoutSCkQh3mDotAq3nwmJqBWD_lgtncRjzv1kLpP56rVCr5s0jfXUwca4QfWlgFtWtSa3NDczsa_skWjiDjCG-feRyRG6XxPwae7u_7KBMibUMX14dfdsA
The keyset that is being used to verify is
I0504 15:19:46.415396 5363 jws.go:344] Key set key is &{%!s(*jwk.StandardHeaders=&{0xc4228ce390 0xc4228ce3a0 0xc4228ce3b0 0xc4228ce3c0 [] map[alg:RS256 kid:772cUKQz9tSQWdwlY86lE2RTwgw9yPJsmM-uZURC3To kty:RSA use:sig]}) %!s(*rsa.PublicKey=&{0xc4227462a0 65537})}
I0504 15:19:46.415934 5363 jws.go:344] Key set key is &{%!s(*jwk.StandardHeaders=&{0xc4228ce3f0 0xc4228ce400 0xc4228ce410 0xc4228ce420 [] map[kid:0pmgYstChDEzMO3xwce6MwGu8WCjA9lWAf83M-tTFg4 kty:RSA use:sig alg:RS256]}) %!s(*rsa.PublicKey=&{0xc4227462e0 65537})}
@nate.barbettini @vijet The key id im getting in my token does not match the key ids present in key set used to validate in SDK.
Also the key ids that I get from https://nutanixdev.oktapreview.com/oauth2/v1/keys is different from what the above SDK uses to verify . The issuer im using while using the above SDK is https://nutanixdev.oktapreview.com/oauth2/default. This key id is also different from what is present in token. So basically all 3 are different.
Needless to say, Im using the https://nutanixdev.oktapreview.com to generate token. Can anybody from okta help?
Since you’re using the default authorization server (https://nutanixdev.oktapreview.com/oauth2/default), you should be seeing the keys at https://nutanixdev.oktapreview.com/oauth2/default/v1/keys (not https://nutanixdev.oktapreview.com/oauth2/v1/keys)
You can use the well-known endpoint for your org to get all the details - https://nutanixdev.oktapreview.com/oauth2/default/.well-known/openid-configuration
Hope this helps.
Just to clarify, the keys you see at https://nutanixdev.oktapreview.com/oauth2/v1/keys are used to sign the requests you make to Okta APIs. (Okta has its own auth server that is used for verifying Okta’s APIs)
The keys at https://nutanixdev.oktapreview.com/oauth2/default/v1/keys are used to sign your APIs that will authorize requests to your resource server.
It seems like this is a configuration issue. If you can post your sample code, we might be able to help.
1 Like
Hi,
I also had a question on verifying accessToken issued by Okta Authorizaton Server (Okta has its own auth server that is used for verifying Okta’s APIs). I assume when there is no default authorization server configured Okta’s own auth server will issue accessToken for OpenID connect application, How can I verify the accessToken signature in that case.
You shouldn’t be using Okta’s auth server for protecting your APIs. (And you don’t have to verify its access token in any case)
If there is no default auth server configured for your org, you can create your own auth server as explained in this document - https://developer.okta.com/authentication-guide/implementing-authentication/set-up-authz-server#create-an-authorization-server
Let us know if you have other questions.
1 Like
Just for my understanding what is the purpose of sending over the accessToken along with the idToken if it can’t be verified or used?
You can always verify the accessToken sent by the auth server.
You only have to use your own auth server (instead of Okta’s auth server) to generate access tokens which protect your APIs.
I’m not sure if it’s clear in my explanation, but read this document to understand the difference between the Okta Org auth server vs. custom auth server - https://developer.okta.com/docs/api/resources/oidc#composing-your-base-url
@Yasinja To add to what Vijet said, the purpose of getting an access token from the Okta org authorization server (/oauth2/v1 instead of /oauth2/default/v1) is to get a token that you can use to talk to Okta if you are building an integration to Okta itself. You can’t verify it yourself because it can only be used to call Okta, and Okta is the system that verifies it.
On the other hand, when you are building a custom application that needs to issue its own access tokens, you need to use a custom authorization server such as /oauth2/default/v1. These tokens can be used by your own code.
It’s a subtle difference that we need to figure out how to explain better I suspect this is also why @prasadj was having trouble validating their token signatures.
1 Like
I’m a bit late to this party but from what I’m reading in RFC 7517
The RSA Key blinding operation [Kocher], which is a defense against some timing attacks, requires all of the RSA key values “n”, “e”, and “d”
But our JWKS result only includes n and e. What steps are needed to verify the signature in this case? It seems like all the Okta servers do this.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.