Martin Mato
When your using jwts with an spa there is still a challenge where users stay logged in on the browser for as long as the token is valid.My question is whats the best way to solve this issue?Do you reduce the token validity duration?
Randall Degges
This is actually a more complex argument. If you’re running a web server (which is what this article focuses on), forking off threads and doing IPC is really slow, error prone, and can cause all sorts of other performance/security issues. The fact is that doing math and cryptographic operations in Node is slow and there is no great workaround for that atm except to NOT doing them in a Node process =)
I can get into more depth here if you’d like, but it’s a whole article in and of itself.
Randall Degges
You should ideally not be using JWTs at all, especially not in SPAs that have no server-side backend. If you do, the best option is to make their TTI/TTL very short to reduce the surface area of token compromise. There are plenty of patterns to follow here (namely, using OpenID Connect) flows (authorization code is ideal, implict would be less ideal).
Igor Savin
Any recommended reading to follow up on that?
Randall Degges
I’ll write up an article and share it here! =)
Harry Moreno
It’d be great if you could expand on why token are a good idea for mobile apps or single page apps. I think they are not better than sessions in cookies but I’d like to here more details.
Akash Srivastava
Well from my experience you make sure JWT tokens are short-lived(upto 5 mins), and then you make use of Refresh Tokens which are long-lived to generate JWT tokens on demand. But it all depends on the application you are building as this article has mentioned very well not every application is suited for JWT tokens, it all depends on the use case.
Pan Con Queso
so, you have problem with ONE point only? because in the article you have more reasons and in that in particular , they clarify that this is maybe the least of the problems
Evgenij
Thanks for this very interesting article. Despite of the different opinions on the usage of tokens this at least gives the people some additional information to make design decisions.
Concerning the content, I wanted to add a note to the statement “…If I ask you for your Venmo address in person, and someone else shouts their Venmo address, I might accidentally send them the money I owe you…JWTs were designed to prevent this sort of thing from happening…”. Actually (if the Venmo address is not contained in the JWT itself), the JWTs can’t safely prevent such situations. If a JWT is stolen/intercepted by somebody, then this person can use it until its expiration and will be accepted by the server. The token’s signature only verifies that it was really issued for the person that is defined in the JWT (subject claim). It can not be used to verify that the sender of the request is actually that person. It can be just anybody, who has the token. Thus, it is really important to transfer the tokens over a secure channel like HTTPS.
Edwin Cloud
#1: So you should never be storing anything more than an id in a jwt IMO… determining a user’s permissions should be done in middle-ware on the server-side.
#2: Similar to #1, you should always be checking server side per request on whether a user is banned or active and their permissions…etc.
Khrisna Gunanasurya
After read this article I kinda wondering should I use JWT for my project, but after read your comment I’m going to use it 
thanks for your explanation
Nick West
JWTs are supposed to be an alternative to sessions so you no longer have to manage sessions on the server/user side. People who try to do sessions with JWTs are just doing it wrong; I get that your intention with this article is to highlight this problem, but flat out saying “JWTs suck” feeds into the misconceptions about the technology, so please consider more nuanced language so as to not spread false sentiment unintentionally.
ukjb
What he said… It’s like building Noah’s ark and them complain we let on 300 ants instead of just 2… How will we overcome that extra weight!!!
Edit. Oh wow, just realized this article is from a year ago lol. My bad
Siddharth
Still your comment is relevant though. Seriously, 24 MBs isn’t much in terms of network bandwidth especially if you have 100k users/month.
p373
What about CORS? This topic seems conspicuously missing.
Calvin Nel
agree please expand on that section.
Calvin Nel
Please continue, as im with you on this so far… and the person above in terms of token being “forced”. its not immediately clear how you solve permissions or data store problems with tokens, seems like its more away of authorizing to an api, rather than a website with different menus/feature/levels, but then why have both one could ague, but then using the token without putting the permissions in the token, how do you know the permissions of given user, are they fetched on every call, or is the standard to put them in the token. lets say you have 100 Permissions that makes your token quite chunky.
Calvin Nel
every request? get user permissions… 100 request, 100 get permissions…
Calvin Nel
Could you correct the English hard to follow what you are actually saying.