The idea of JWT is basically you give your user a "token" that can be used against many "services" while servers don't have to persist the state of that token, just be able to read the encrypted token, and trust the information in the token. The obvious issue is the server cannot easily revoke that token without blacklisting it, therefore persisting that token somewhere on a blacklist on the server. If you are going to make a lookup for a token in a blacklist you might as well look up for a session ID to being with.
Stop using JWT for sessions (2016)
21–30 of 255 posts
Re: Stop using JWT for sessions (2016)
#22Can someone explain the Cookie vs LocalStorage thing? You can access cookies from Javascript, so how is localstorage worse? Assuming an attacker can execute arbitrary js in the browser (the model provided by the article).
edit: Thanks for the answers - httponly, makes sense.
Re: Stop using JWT for sessions (2016)
#23From my time browsing HN, the consensus seems to be "don't use JWTs". What is the preferred method of client authentication for simple APIs these days?
Re: Stop using JWT for sessions (2016)
#24Earlier quoted context omitted.
Not true. Encode a token and validate it against a constant, which you change in case of a compromise.
So you're saying you can have sane sessions as long as you have some server-side storage? :-)
Yes, of course, jwt can facilitate that. Using it as a replacement is not good, i agree.
Re: Stop using JWT for sessions (2016)
#25Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…
Why not just "invalidate" the client? At best, you're making your application "safe" for 900ms or whatever the expiry date is.
What do you mean by "invalidate the client"?
Re: Stop using JWT for sessions (2016)
#26what about setting a secure cookie with a jwt, and expiring it when you log-out? what is the utility in server-sessions? (aside from the ability to revoke it at any time from the server.)
> and expiring it when you log-out?
and how would you do that if the user doesn't actively log out of a service?
Re: Stop using JWT for sessions (2016)
#27Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…
Not true. Encode a token and validate it against a constant, which you change in case of a compromise.
Or, implement a "master token" scheme: have a long-lived master token, which is used only for generating short-lived (e.g. 5 min) tokens that are actually used for authentication/authorization at the API endpoint.
User gets banned or privileges revoked? Fine, revoke the master token on the authentication server and after 5 minutes at the latest, the user is locked out as he cannot get new valid short-lived tokens.
Sessions aren't difficult - as long as you stick to one language and environment (e.g. PHP). But as soon as you throw in for example Java to communicate with a SAP backend (as an online-shop system might need to), nodejs for a "support/sales chat" system and whatever, a JWT scheme is easier to implement.
Re: Stop using JWT for sessions (2016)
#28I used to be very opposed to JWTs but I can see some interesting use cases for them now, at least when using the variant based on public key cryptography. For example, if you need/want the ability to verify token validity locally (i.e. without making a call to you auth backend) they are very handy: Generate a token, sign it using the auth backends' private key and clients can verify it using the public key.
That said, I wouldn't use them as a default authentication mechanism as invalidation requires a connection between clients and auth backend again, as many people here pointed already out. It might still be easier to establish such a channel though than continuously verifying traditional tokens via the backend, which you can solve differently though as well: For example, for our APIs at KIProtect we cache validity information for (hashed) access tokens for 60 seconds on the API server, and we refresh the tokens in the background 30 seconds before they expire (if triggered by a request). Like that we can ensure that invalid tokens cannot be used after a short grace period (60 seconds is good enough for us) while not slowing down clients that perform many API requests as the token needs to be fetched only for the first request and will then never leave the cache (as it gets updated) if the client performs at least one request roughly every 60 seconds (or more often).
Re: Stop using JWT for sessions (2016)
#29It's an interesting reading (together with second part), but should be taken with a grain of salt.
Stateless sessions are useful under load and not necessarily under reddit-size load. I like 2-layered setup actually with long-expiration (1 year) "session" cookie kept on `auth.example.com` domain and short-lived (1 hour) JWT-cookie kept on `example.com` domain. JWT can optionally include permission for dangerous operations which is not automatically granted.
You still need redis to take care of forceful expiration, but that would be very simple call to the small list (1 hour of force-expirations if you reissue jwt-tokens on hourly basis), not data-fetching calls. We can keep this in a tiny redis-cluster colocated with frontend machines. JWT would have enough data to personalize cached templates. This will render really fast.
API-backend, database and larger redis-storages can be kept deeper in logical server-room and be accessed only on cold requests
Re: Stop using JWT for sessions (2016)
#30what about setting a secure cookie with a jwt, and expiring it when you log-out? what is the utility in server-sessions? (aside from the ability to revoke it at any time from the server.)
Do you mean "delete the cookie" with "expiring it"? Then that doesn't help against an attacker which already has obtained the JWT, they can still use the JWT until it's expiry.