4 ms·
Everyone seems to be posting the "stop using JWT" article from 2016. It has a lot of merit, but I think there is small logic hole in it. When the second part at
by MadWombat 7y ago
Everyone seems to be posting the "stop using JWT" article from 2016. It has a lot of merit, but I think there is small logic hole in it. When the second part attempts to address the issues of token revocation, its only argument is "what if your blacklist is down?". But that is silly. Blacklist is part of your authentication process, if it is down you don't authenticate. Its like asking how would you serve your API if your API server is down. You won't, your server is down.
Otherwise, blacklisting tokens as a way of revocation process seems just fine to me. Set reasonable expiration to the key, allow users to refresh keys, then when you need to revoke a key, add it to blacklist together with the expiration timestamp and expire it out of the blacklist at the same time the key itself would expire. You can do all of this by magic by using Redis for your blacklist storage and setting expiration on your blacklisted keys. Yes, you would need to check your blacklist on every request, but a) blacklist is going to be smaller than a list of every issued token (like you would with normal sessions) b) you don't even have to store the whole token, just calculate some hash and store that, now you only need to read a few bytes on every request instead of reading the whole session.
The author does make a some good points though.
- zackbloom 7y agoIt's also possible to do your token validation in something like Cloudflare Workers and store your blacklist in Workers KV. That would mean it lives all around the world closer to your users than your origin, making it unlikely it is adding meaningful latency to check it. Disclaimer: I work at Cloudflare
- tggg33 7y agoBut there’s a limit of 5000 requests per 10 minutes with cloudflare workers. This kind of usage will never go well with that limit.
- jsty 7y agoWhere did you see that? I've skimmed their limits page [0] and there doesn't seem to be any request limits for paid plans. [0] - https://developers.cloudflare.com/workers/about/limits/ https://developers.cloudflare.com/workers/about/limits/
- kentonv 7y agoThere is no such limit. We have individual customers doing hundreds of thousands of requests per second. (Disclosure: I'm the lead engineer for Workers.)
- NewEntryHN 7y agoThe argument is that the blacklist is as much a SPOF as a session server would be. The blacklist kills the statelessness.
- enraged_camel 7y agoExactly. Even if it's not a SPOF, it becomes yet another piece of architecture you need to worry about distributing and scaling (if you're at the point where JWTs are attractive to you due to their scalability).
- james_s_tayler 7y agoDoes that negate all the benefits though? If a single component of your application maintains a little state, say the API Gateway, and all the downstream services simply get a clean JWT they can trust with all the right claims in it? I'm thinking this is still nicer than having every downstream service also having to check auth claims against some datastore.
- jeltz 7y agoYes, because then the API gateaway could instead just use traditional sessions and attach relevant data when forwarding the request downstream.
- deleted 7y ago[deleted]