Securing a web application or api requires actually validating the access token that is being used. When using JSON web tokens (JWTs), there are two mechanisms for doing this. But the core of the solution requires inspecting that JWT, understanding who the authority is, and using that authority for verification.
The properties or fields in a JWT are called claims. JWTs contain an ISS claim. This is the Issuer. The issuer is the authorization server (AS) which is marked by the issuer. As such the AS provides a full document about how JWTs are constructed and how to verify them. This document must always be found at https://${Issuer}/.well-known/openid-configuration (according to RFC 8414). Here’s a real life example.
What’s more is that the openid configuration may inform you of an introspection endpoint. By passing the token there the AS will tell you if the token is a valid one. However, not only is this optional, it is expensive since the results can not be cached. If you are verifying 1000s of tokens per second, it is far too prohibitive to verify them like that.
JWTs are signed, that means they have a signature which allows them to be verified. With the signature, they also contain a kid which specifies which public key was used to sign the token and create the signature.
A better alternative is to use the issuer, kid, and signature to verify the token. To do this get the relevant JSON Web Keys (JWK). Use the issuer to get the keys, find the right key using the kid, and then verify the signature using the key. Therefore keys allow you to self verify the token much faster and the keys themselves are cacheable, that means that you can avoid frequent API calls by using the JWKs. This still has a similar problem as the introspect endpoint; that is you are implicitly trusting the issuer. So step one becomes:
After that, verify to token, just break open the token grab associate JWK and verify the signature:
Originally published at https://authress.io on November 8, 2020.
Top comments (0)