Pitfall When Using Java Okta SDK JWT Verifier
In today’s quick post I would like to cover a pitfall that I have seen several developers fall into when using the Okta Java SDK when verifying JWT signatures. I have found it interesting that two independent teams working on integrating with Okta via Oauth2 have run into this same problem when verifying JWTs.
When you receive a JWT from a client you need to verify its signature before you can trust any of its data. As you may know, the content of a JWT is just base 64 encoded data and any client could just change that content to whatever they want. What prevents them from doing this is the signature at the end of the token. This token can be generated in a several different ways but a popular method is with public/private key cryptography. This is useful in that anyone can use a public key to verify the authenticity of a JWT without the ability to use that same key to generate a signed JWT of their own (this would be possible with a symmetric key).
While conceptually this is fairly simple the mechanics of how this works with Oauth2 is a bit of a pain. Thankfully the Okta Java SDK provides an interface AccessTokenVerifier that, once you have an instance of it, you can verify the authenticity of a token and retrieve its data. A convenient way of creating an instance of an AccessTokenVerifier is via the JwtVerifiers builder class. This code…
