Oct 05, 2022
Oct 05, 2022
JWTs have won. It's time we embrace them and fix the dangerous implementations.
This week there was a fresh batch of debates about JWTs as session tokens on Hacker News. For the uninitiated, this happens incredibly frequently on HN, to the point where moderator dang has posted roundups:
Just about every thread goes the same way:
Why the trepidation on 4? Usually, it's because 3 is easier. Here's one viral post's rationale (they refer to stateful session tokens as bearer tokens):
[...] you've just reintroduced a bearer token, because that's exactly what the refresh token is. Looking at JWTs from that perspective, you've introduced a client-side cache of user identity (the JWT) and added a bunch of complexity (involving the creation, verification, and token refresh) for the hope of optimizing part of the work you used to do on the server (checking user identity using a bearer token). Was it worth it?
The author is right: The complexity of 4 is high and the benefits for the 99% case are minimal.
Yet, JWTs are clearly winning. Their usage has grown, not dwindled, while two major trends in software development have increased their demand.
This has been a trend for decades. It's impressive that today's developers care about a 10ms query vs a <1ms JWT, but it's not surprising.
The simple reality is that Google Lighthouse scores – and the wealth of evidence supporting that users prefer fast applications – have placed an unprecedented emphasis on loading speed.
The developers who care most are no stranger to complexity, as they're often thinking about problems like distributed storage and operating at the edge. It's no surprise they're eager to treat one less query as an easy win.
This trend is more recent. Third-party integrations are sweetening the buy-vs-build deal by doing more for their customers. If an integration knows which user is signed in and their permissions, then it can expose APIs directly to the frontend, and even offer user-facing UIs as part of their service:
The newer a tool is, the more likely it is to allow syncing sessions by JWT.
These trends aren't going anywhere. It's time we embrace JWTs and fix the bad implementations that have stained their reputation:
Check your application code. If you use stateless JWTs (no database check) and they don't expire in 5 minutes or less, report it to your security team.
Don't generate session JWTs with a lifetime greater than 5 minutes. If developers want to configure a longer lifetime, warn that it's bad practice for XSS attacks.
Provide a refresh mechanism that depends on a HttpOnly cookie in the browser.
Don't accept session JWTs with a lifetime greater than 5 minutes. If you must, warn developers that it's bad practice for XSS attacks.
Critically, provide developers with a mechanism to send a new JWT after the first JWT expires – don't receive a JWT once and then manage an independent session.
Yes, long expiration is the #1 most common security mistake with JWTs. It leaves many sites especially vulnerable when XSS attacks or account takeovers occur.
Yes! Clerk's session JWTs default to a 1 minute lifetime, and our refresh mechanism depends on an HttpOnly cookie. We even offer "Active Device" management in our <UserProfile/> component so end-users can revoke their own sessions.
Start completely free for up to 5,000 monthly active users and up to 10 monthly active orgs. No credit card required.
Learn more about our transparent per-user costs to estimate how much your company could save by implementing Clerk.
The latest news and updates from Clerk, sent to your inbox.