Hi @joprice
Thanks for the PR. First of all, the only operations you're saving processing time in is the JSON parsing of the header/payload, and maybe the String.split() and Base64.decode() which are not as heavy as the signature verification that you're still doing on this new method so I don't think it's a win. Of course it always depends on the algorithm and size of your token, which we suggest you keep short.
Adding to that, the Algorithm and JWTVerifier classes are meant to be reusable, so you should be able to configure a single instance and use it widely (as long as your requirements doesn't change on runtime). If your concern is to access the kid or even the already verified DecodedJWT, why not just keep the value in a variable? Provide more context on how you're using the library so we can understand.

Cheers,

The use case is looking up the public key dynamically based on kid.

@joprice I think it's confusing to have another verify method that receives and returns DecodedJWT. I would keep the existing signature as it is, and let the one that you're suggesting return void instead and just throw if something goes wrong inside.

Something like this:

public DecodedJWT verify(String token) throws JWTVerificationException {
          DecodedJWT jwt = JWTDecoder.decode(token);
          verify(jwt);
          return jwt;
}

public void verify(DecodedJWT jwt) throws JWTVerificationException {
          //perform the actual verification
}

Please add the corresponding javadoc+tests.
Cheers,

Before the above, I think you should look at this PR #149 as it adds support for KeyProviders, which seems to be what you need for the key look up. Will be available soon in the next release.

I don't see an example of looking up a key based on an id. The provider interface doesn't take any input.

@joprice will close this one since we rather improve on what @lbalmaceda mentioned for allowing using rotating keys.

We'll try to provide an example in the README and here too

Sounds good.