Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop using JWT for sessions (2016)

cryto.net

Post reply on HN
Print view View original

181–190 of 255 posts

Re: Stop using JWT for sessions (2016)

#181

Post by detaro »

cryptica wrote: post #171
abledon wrote: post #68

Earlier quoted context omitted.

How the heck did JWT get such a following with issues like these?

This article is propaganda. This is not the first article of its kind; they just keep popping up over and over on HN with the same poor arguments. I usually take the time to write long explanations as to why these points are invalid but I'm tired of arguing with these people. The real reason for these articles I think is that some developers had a very traumatic experience with a poorly implemented JWT authentication…

Could you explain why they're important for WebSockets? Hadn't heard about them in that context before.

Re: Stop using JWT for sessions (2016)

#182

Post by yihangho »

AndrewSChapman wrote: post #133

I'm not 100% sold. I think JWT's are fine in some situations as long as you know the limitations. Regarding session invalidation, I would handle this in two ways. 1. Support a "Log everyone out" function by storing a simple version number in the JWT. If the version constant in your app is different to the number in the JWT, it is invalid. 2. Support a "I need to logout user X function" by storing a blacklist of token…

Well, the RDBMS solution is precisely a stateful infrastructure that (the author claims) “defeats the entire point of using stateless JWT tokens.”

Re: Stop using JWT for sessions (2016)

#183

Post by unclebucknasty »

kbenson wrote: post #173
ale_jrb wrote: post #169

Earlier quoted context omitted.

This is true, but kicking off a large subset of the userbase every time an account is compromised (or more realistically, every time someone changes their password—which should certainly invalidate their old tokens) isn't going to be a valid trade off for most applications with customers.

You don't have to kick them off. You can make it a trigger to just check whether their session has been invalidated. Store last password change date or something similar, and if the db user is still valid and the password date is older than the JWT creation date, just update the JWT and let them continue. If not, require a new login procedure or deny outright, depending on account status. > every time someone changes…

>It's a trade off

But, what are you getting for this added complexity--above and beyond what "traditional" user session management provides?

Re: Stop using JWT for sessions (2016)

#184

Post by Tade0 »

A huge part of the issue with JWT is that it's often used wrongly.

I'm currently in a project where JWT is used. We have a list of searchable items and each one of them holds a gallery of photos - up to 5MB per photo.

The issue at hand is that these photos are served from a certain endpoint which we eventually want to secure, but the back-end's idea here is for the front-end to download the photos via XHR putting the token in the Authorization header - they refuse to send the JWT via cookie saying that it's "incompatible with JWT".

Re: Stop using JWT for sessions (2016)

#185

Post by anon1252 »

manigandham wrote: post #178
anon1252 wrote: post #174

Earlier quoted context omitted.

Yes it does mean something. a session is something that is identified by an ID on the client and is persisted on the server with the corresponding ID. It's a concept. It doesn't have to be stored in a cookie. A session can be represented by a token and stored in any client side storage.

Ok, yes, session is a concept. Session state can be stored in its entirety or split between an ID and body. You can send it all to the client or you can send just an ID and lookup the body on the server. You can send it to the client via the cookie header or via the Authorization header or something else. You can encode the data (sent via cookies or auth header) as a JWT or your own encryption scheme. These are all d…

> Ok, yes, session is a concept. Session state can be stored in its entirety or split between an ID and body.

the storage of session has absolutely nothing to do with the session. I'm not sure why you keep talking about Cookies it has nothing to do with the problem. JWT can be persisted with cookies as well.

Re: Stop using JWT for sessions (2016)

#186

Post by bearjaws »

kbenson wrote: post #173
ale_jrb wrote: post #169

Earlier quoted context omitted.

This is true, but kicking off a large subset of the userbase every time an account is compromised (or more realistically, every time someone changes their password—which should certainly invalidate their old tokens) isn't going to be a valid trade off for most applications with customers.

You don't have to kick them off. You can make it a trigger to just check whether their session has been invalidated. Store last password change date or something similar, and if the db user is still valid and the password date is older than the JWT creation date, just update the JWT and let them continue. If not, require a new login procedure or deny outright, depending on account status. > every time someone changes…

We tie our users session in the JWT to the session in a central database, this allows us to invalidate individual sessions.

The reason for using JWT is that the UI and backend consume the same session object seamlessly. Before what we got in our PHP session and what state we shared with the UI were manually kept in sync through a API request.

Re: Stop using JWT for sessions (2016)

#187

Post by dchest »

tschellenbach wrote: post #167
abledon wrote: post #68

Earlier quoted context omitted.

How the heck did JWT get such a following with issues like these?

The article exaggerates these issues. Also there are easy solutions available for those concerns. It's trivial to store a token version on your user object and invalidate any token that has the wrong version.

Then just store session ID there and get rid of JWT.

Re: Stop using JWT for sessions (2016)

#188

Post by manigandham »

anon1252 wrote: post #185
manigandham wrote: post #178

Earlier quoted context omitted.

Ok, yes, session is a concept. Session state can be stored in its entirety or split between an ID and body. You can send it all to the client or you can send just an ID and lookup the body on the server. You can send it to the client via the cookie header or via the Authorization header or something else. You can encode the data (sent via cookies or auth header) as a JWT or your own encryption scheme. These are all d…

> Ok, yes, session is a concept. Session state can be stored in its entirety or split between an ID and body. the storage of session has absolutely nothing to do with the session. I'm not sure why you keep talking about Cookies it has nothing to do with the problem. JWT can be persisted with cookies as well.

Yes, my original and last comments already said exactly that... I'm not sure what you're arguing at this point.

Re: Stop using JWT for sessions (2016)

#189

Post by sebringj »

Short lived JWT is ok for stitching desperate micro services together as it saves round trips to verify things but I prefer mystery tokens when using more intimate services that have access to similar underlying stores to verify them. Basically use them appropriately and they are fine.

Re: Stop using JWT for sessions (2016)

#190

Post by kbenson »

unclebucknasty wrote: post #183
kbenson wrote: post #173

Earlier quoted context omitted.

You don't have to kick them off. You can make it a trigger to just check whether their session has been invalidated. Store last password change date or something similar, and if the db user is still valid and the password date is older than the JWT creation date, just update the JWT and let them continue. If not, require a new login procedure or deny outright, depending on account status. > every time someone changes…

> It's a trade off But, what are you getting for this added complexity--above and beyond what "traditional" user session management provides?

You can serve pages that don't require DB access without ever hitting the DB. Static content that is restricted to authed accounts is able to be served immediately and directly. Requests that access resources other then ones shared with the auth system do not need to first access the auth system to verify the account. Even if the auth system is on the same DB as the rest of the content, it's no longer a sequential bottleneck.
Post reply on HN