JWT Auth: How is irrevocability an acceptable tradeoff?

21 views Asked by At

I'm trying to understand a part of the general philosophy behind JWTs.

I've read in several articles around the internet that JWTs are irrevocable by design. In other words, once a valid token is issued, there is no way to revoke it other than just waiting for it to expire, unless I keep some sort of state on the server which would seem to defeat the #1 benefit of using JWTs. Please correct me if this is a faulty premise for my understanding.

What I'm trying to understand is how can this possibly be considered an acceptable tradeoff? If someone managed to get a passkey to my house, I'd never just be like "Well, you have 5 minutes until the code expires to poke around as much as you want and grab what you can." The idea is laughable, I'd want the person's access revoked immediately. But isn't that how we're treating user data with JWTs? I'm hoping that I'm grossly misunderstanding this!

I can never guarantee that a malicious party won't somehow manage to get a user's JWT due to mistakes on their part, but it seems like it would be a standard expectation for me to offer my users the ability to at least log themselves out everywhere (revoking access for all unexpired tokens) so that malicious party's access can be blocked immediately.

So here are my thought questions:

  • If this tradeoff is indeed considered acceptable, why?
  • Doesn't this make JWTs a complete no-go for stricter security requirements like HIPAA or are there approaches for getting around this problem with JWTs? If there are solutions, I'd love to see some links to articles that dive into possible implementations. Are there still advantages to using JWTs with potential workaround to this problem versus good old-fashioned server-side session storage, and what are the advantages?
0

There are 0 answers