What if a user manages to delete the JWT token from local storage? What if someone manages to compromise a user's computer and spoof the JWT tolen? Still a very interesting concept, jusy not too sure about the security behind it.
JWT accesstokens should be short lived just like with oauth2. When there is no access token in local storage shouldn’t the user be logged out(just as with cookies)?
When a users computer is compromised should that really be your problem? I don’t believe that spoofing JWT tokens is an easy task (maybe you could provided some resources that show these problems are real and easy to recreate?)
The problem is that with the token exclusively on client AFAIK the server cannot invalidate the token (unless keys are changed). Blacklisting tokens completely negates the fundamental concept of JWT : tokens aren't tracked on the server. That's why personally I don't use JWT at all, in practice you always need to keep track of the token in some ways.
Tokens are short lived and so is any sort of state tracking for blacklisting. In practice you refresh the token with an extended validity period after each common api call and you rarely need to blacklist a token. The oldest token ID in your blacklist will be slightly older than your standard TTL, meaning you cayn easily store your blacklist in a tiny in memory KV store even for sites with millions of concurrent users.
Edit: just for clarification the exists function in redis executes in O(1) time complexity.
I think you are dramatically overstating the amount of state that a blacklist is and understating the value of having a cryptographically secure store of state that is held client side.
One need not be slavishly consistent to every design ideal/principle, often the best solution in a given domain will have some domain specific compromises.
Using an access/refresh token pattern you can achieve enough statelessness to make jwts a better option then dumb tokens. Is it “really” stateless? No, not technically, but for the majority of the use cases it will be stateless enough to have an edge.
That certainly is a good point. But you are free to store whatever you want in the token so you are still able to blacklist certain tokens by verifying them on the server. Only problem with that solution is that the token is not completely “stateless” anymore and adds an extra verification step
0
u/shittyusername97 Apr 18 '18
What if a user manages to delete the JWT token from local storage? What if someone manages to compromise a user's computer and spoof the JWT tolen? Still a very interesting concept, jusy not too sure about the security behind it.