This seems to be targeted at web apps. I take it I don't need to remove JWT token support from all of my mobile applications?
Stop using JWT for sessions (2016)
121–130 of 255 posts
Re: Stop using JWT for sessions (2016)
#122Sorry, I'm going to be a contrarian here. JWTs can be good.
First, cookies-vs-local storage is a non-issue here. If a JWT is small, it can be put in either location.
The only real issue is, should session state be on the client or on the server?
Suppose you have an app with large numbers of users, doing hundreds+ of queries per second across many boxes. If you put session state on the server, then you must either 1) have sticky sessions, which generate problems when a server goes down; 2) have a central session server, which generates scalability and reliability problems; 3) have a Redis-like distributed system, which either a) must do one or more server-to-server round trips on every client call to validate the session, or b) cache session information on a node.
When latency matters, an extra server-to-server round trip is a non-starter. And if you do server-side caching, then cache invalidation and JWT invalidation present similar problems. ("There are only two hard things in Computer Science: cache invalidation and naming things.").
Server-side sessions don't really buy you much. If you're using a system that has them built in, lovely, but if you're not, it's a lot of extra work.
JWT is a good solution to the problem. You can store small amounts of session state on the client and simplify the whole system. You can avoid having to do lookups to determine state variables. (What database was the user connected to? Is he in mode A or mode B? What timezone? What language?) Put a short expiration on the token (a minute? five minutes?) and force the user to re-validate against some data store after that.
The benefit is that you greatly reduce internal server traffic at the cost of not being able to invalidate a session within your short timeout interval. Depending on your app, letting someone remain an admin for an extra minute is not a big deal.
And if it is a big deal, you can still handle it by sending a message to each node telling it to invalidate that particular user. A pain, yes, but the tradeoffs may be worth it.
Re: Stop using JWT for sessions (2016)
#123"You cannot invalidate individual JWT tokens"
This is not exactly true. There are lots of things you can do to expire tokens. For instance, every JWT has a creation date stamp so you could say on the server side all tokens created before Time.Now() no longer accept as valid. Allowing users to expire ALL tokens, etc.
Re: Stop using JWT for sessions (2016)
#124Earlier quoted context omitted.
Perhaps, but what they actually are is a standard way to encode some data. Whether that's a single number or entire user session state is up to you. And how you pass that data back and forth is up to you. There are some common usage conventions but the limits described in this article are completely arbitrary.
Nobody here was arguing about what JWT is, the article is about how they're often abused in an attempt to obviate server-side persistent data storage in pursuit of "scalability". The title is "Stop using JWT for sessions" not "Stop using JWT". The arguments against JWT themselves are wholly separate: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
The basis of that entire argument is based on a false understanding of what JWTs are and how HTTP state transfer works.
If you want to say that client sessions should not be 100% on the client side and should be split between client/server then just say that. There are pros/cons but at least that is a clear argument instead of misleading about JWTs.
Re: Stop using JWT for sessions (2016)
#125Earlier quoted context omitted.
Having recently joined a project that uses JWT (I was completely ignorant of it beforehand - cookies all the way ), I can say that a key advantage is convenience for developers and testing. Once you have the secret for signing you can pretty much access any of the application without having to jimmy the access-controls. I guess that could be a weakness too, but in my experience in fast moving commercially driven envi…
> JWT (I was completely ignorant of it beforehand - cookies all the way) JWTs can be stored in cookies. So I don't understand why you say this.
Oh I'm not aware of the means of using JWT you describe. I think the context of this article is using JWT exclusively, and by the looks of things plenty of people are doing just that.
Re: Stop using JWT for sessions (2016)
#126Sorry, I'm going to be a contrarian here. JWTs can be good. First, cookies-vs-local storage is a non-issue here. If a JWT is small, it can be put in either location. The only real issue is, should session state be on the client or on the server? Suppose you have an app with large numbers of users, doing hundreds+ of queries per second across many boxes. If you put session state on the server, then you must either 1)…
> If you're using a system that has them built in, lovely, but if you're not, it's a lot of extra work.
They're built in with PHP and most Node.js frameworks I've ever worked with.
I'm not sure about Python, RoR, etc. web frameworks but the engineering overhead for adopting server-side sessions should approximate 0, since they're usually the default.
Re: Stop using JWT for sessions (2016)
#127Sorry, I'm going to be a contrarian here. JWTs can be good. First, cookies-vs-local storage is a non-issue here. If a JWT is small, it can be put in either location. The only real issue is, should session state be on the client or on the server? Suppose you have an app with large numbers of users, doing hundreds+ of queries per second across many boxes. If you put session state on the server, then you must either 1)…
Also you're typically already looking up the user so you can just add a token_version property on the user and increment it when you want to expire tokens for that user. JWT problem solved without any additional work for the db.
Re: Stop using JWT for sessions (2016)
#128Earlier quoted context omitted.
Nobody here was arguing about what JWT is, the article is about how they're often abused in an attempt to obviate server-side persistent data storage in pursuit of "scalability". The title is "Stop using JWT for sessions" not "Stop using JWT". The arguments against JWT themselves are wholly separate: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
The basis of that entire argument is based on a false understanding of what JWTs are and how HTTP state transfer works. If you want to say that client sessions should not be 100% on the client side and should be split between client/server then just say that. There are pros/cons but at least that is a clear argument instead of misleading about JWTs.
> The basis of that entire argument is based on a false understanding of what JWTs are and how HTTP state transfer works.
I don't even see why you believe this to be the case. The article (and the follow-up) are both pretty clear about what the actual issue is.
Did you read them or just react to the headline?
Re: Stop using JWT for sessions (2016)
#129Earlier quoted context omitted.
Not true. Encode a token and validate it against a constant, which you change in case of a compromise.
What's the point of having a token if you need to check it with a database on every request? Instead of `SELECT isValid from tokens where token=" "`, why not `SELECT user from sessions where session=" "`?
With jwt you have a standarized way to get
the data on the client side for example.
Re: Stop using JWT for sessions (2016)
#130The 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…
Traversing a list of 100,000 users/sessions in a db to pull up the session is a different beast compared to traversing an in memory list of 10-100 revoked JTIs in redis. It is a lot less data to store and optimize (the full session vs. a small list of revoked JTIs)