JWT Verification in Java

[WilliamNoad]

We’re having problems using the okta-jwt-verifier-java in our application, and need a little bit of guidance.

Our application is Spring Boot on Tomcat, providing a set of REST endpoints for a single-page Angular application. For (complicated internal business) reasons the Okta authentication/authorisation processes were retrofitted to the front-end late in the development process (part-way through UAT.) Redeveloping the existing code to leverage Spring Security is not an option, so we’re trying to validate the access token using the library.

The symptom is that the library is throwing various exceptions during the decode call.

• If the issuer is set to https://*******.okta-emea.com/oauth2/default/ the exception reports a 403 error on the /oauth2/default/v1/keys endpoint
• If the issuer is set to https://*******.okta-emea.com/oauth2/, the library gets a 403 error requesting /oauth2/oauth2/v1/keys
• If the issuer is set to https://*******.okta-emea.com/ which matches the front-end’s configuration, we get a warning that the issuer should be of the form https://{yourOktaDomain}/oauth2/qualifier, followed by an illegal argument exception A signing key must be specified if the specified JWT is digitally signed.

The keys are available to us from the URL https://******.okta-emea.com/oauth2/v1/keys, so it looks as though we’re missing a trick in configuring the library.

If it’s relevant we’re using Okta for SSO, integrated with our Windows AD.

Has anyone else seen or solved this problem?

[Govner]

Remove the trailing slash and set to https://*******.okta-emea.com/oauth2/default

[WilliamNoad]

I tried that: I get the error Failed to fetch keys, exactly the same as in the first bullet point.

The keys are not available from that endpoint, only /oauth2/v1/keys.

[vijet]

Hi @WilliamNoad

Just to be clear here, are you protecting the REST endpoints on the spring application using the access token obtained by the front-end?
If so, you will have to be aware of the following things -

The front-end config should have the ISSUER set to https://*******.okta-emea.com/oauth2/default
This is the default authorization server included in your okta org.
You can verify it by logging in as admin to your org, and navigating to Security -> API -> Authorization Servers
You should see something like this -

If this is not available, you can create a new authorization server, and name it default (or any other name convenient)

You can check the config to use from this link as well - https://*******-emea.com/oauth2/default/.well-known/oauth-authorization-server

To clarify a few things, the endpoints that your application/backend should call should always be of the prefix https://*******-emea.com/oauth2/default.

https://******.okta-emea.com/oauth2/v1/keys contains the keys for the authorization server of your okta org i.e. it is the server that protects Okta’s endpoints.
https://******.okta-emea.com/oauth2/default/v1/keys contains the keys for the authorization server for your application (created by okta for you) i.e. it is the server that protects your application endpoints.

I know it’s a bit confusing. Read this link for more details - https://developer.okta.com/docs/concepts/auth-servers/

Hope this helps.

[bdemers]

Hi @WilliamNoad!

Try what @vijet suggested first, and if that doesn’t help contact support (or your sales rep) and make sure you have “API AM” enabled on the Org you are using for testing.

Keep us posted!