It’s week 3 of 365 Days of Passport. Today, we are going geek on you. Let’s talk about JWTs (JSON Web Tokens).
JWTs are becoming more and more ubiquitous. CIAM providers everyone are pushing JWTs as the silver bullet for everything. JWTs are pretty cool, but let’s talk about some of the downsides of JWTs and other solutions you might consider.
The way I usually describe JWTs is that they are portable units of identity. That means they contain identity information as JSON and can be passed around to services and applications. Any service or application can verify a JWT itself. The service/application receiving a JWT doesn’t need to ask the identity provider that generated the JWT if it is valid. Once a JWT is verified, the service or application can use the data inside it to take action on behalf of the user.
I have been talking with developers about JSON Web Tokens (JWTs) recently and a one question keeps coming up: “How do I revoke a JWT?”
If you poke around online, you’ll find that the most common answers are:
- Set the duration of the JWT to a short period (a few minutes)
- Implement complicated blacklisting techniques
There is not a simple solution because JWTs are designed to be portable, decoupled, identities. Once you authenticate against an identity provider (IdP) and get back a JWT, you don’t need to ask the IdP if the JWT is valid. This is particularly powerful when you use RSA public/private key signing. The IdP signs the JWT using the private key and then any service that has the public key can verify the integrity of the JWT.
Here’s a diagram that illustrates this architecture:
The Todo Backend can use the JWT and the public key to verify the JWT and then pull the user’s id (in this case the subject) out of the JWT. The Todo Backend can then use the user’s id to perform operations on that user’s data. However, because the Todo Backend isn’t verifying the JWT with the IdP, it has no idea if an administrator has logged into the IdP and locked or deleted that user’s account. Continue reading