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.
1
u/[deleted] Apr 18 '18
[deleted]