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

Stop using JSON Web Tokens for user sessions

ds-security.com

Post reply on HN
Print view View original

51–60 of 145 posts

Re: Stop using JSON Web Tokens for user sessions

#51

Post by bob1029 »

had-rien wrote: post #18

I've been exploring best practices for session storage, and it seems like using HTTP-only cookies the only secure choice. However, I've hit a roadblock when trying to implement a login feature within an iframe, especially with Safari disabling cookie functionality in iframes. This has left me pondering alternatives for secure user authentication within iframes. Has anyone encountered a similar challenge or found a wo…

I had a problem with cookies on iOS/safari, so we reached for the last hope: url query args.

Works flawlessly now. If you use an external identity provider, you can hypothetically avoid storing any cookies at all in first party terms. All you'd have would be 3rd party AAD tokens or whatever.

The only reason we even need first party client state is because we want to allow each user simultaneous app sessions that have lifetime decoupled from IdP semantics. This is what we store in the URL query (a guid). Sessions are still bound to user principals, so you would get yelled at if you tried to screenjack someone else's.

Re: Stop using JSON Web Tokens for user sessions

#52

Post by drekembe »

Weird article. Like others have said, it's mostly about XSS.

It's strange that the article doesn't discuss at all where the JWT is stored in that case. It's one thing if it's stored in local storage (I would avoid that) and a completely different thing if it's stored in-memory so that potentially malicious scripts don't have access to that location.

Re: Stop using JSON Web Tokens for user sessions

#53

Post by jFriedensreich »

jFriedensreich wrote: post #45

i really don’t understand how the article assumes jwt s are not stored in http only cookies. Jwts are an encoding method you can use them to implement a wide array of usecase and if they are used for sessions of course the security best practices for session cookies have to be met, that has nothing to do with jwts except that they require special thought compared to server side sessions when it comes to things like i…

and when it comes to reading claims and other data from jwts, no one in its right mind would do that by making the session cookie available directly to js client code, so this is a total straw man argument. this is achieved either by making those available separately with means to validate signature but not usable as session token itself or/and by having a session endpoint on the server that reads and validates the jwt and responds with the data from it with the advantage of being able to also add additional session information that is not encoded in the jwt and only available on the server.

Re: Stop using JSON Web Tokens for user sessions

#54

Post by Aldipower »

Just do not store JWTs in LocalStorage or any JavaScript accessible location. Use secured httpOnly cookies. Validate the JWT on server-side _stateless_. No need for a database. This idea is so good and it works! Just follow best security practice. If you don't, it is not the fault of the JWT. Bad blog article..

Yes, things like Keycloak and such follow _bad practice_. Still not the fault of JWT.

Re: Stop using JSON Web Tokens for user sessions

#55

Post by Ironlink »

isodev wrote: post #9
Maxion wrote: post #5

It's interesting how much of an upward hill battle it has been for me to argue that JWT tokens need to be stored in cookies rather than LocalStorage. In my latest project, the lead backend dev is convinced it is insecure to store the accessToken in a HTTPOnly cookie, and that it HAS to be stored in LocalStorage.

I'm curious what were their reasons - it's hard to imagine how localStorage would be "more secure" than http only cookies. It's not a zero-sum situation. There are risks and vulnerabilities in every approach, that's why we as web devs take advantage of multiple safeguards to ensure safety when sensitive information is to be transmitted over the wire.

My best guess is that they are thinking of CSRF. With cookies, requests automatically carry the token, whereas with local storage you need to explicitly add the token. However, CORS does a lot to improve this situation. I note that CORS allows posting form data without pre-flight, but it is not immediately clear to me if posting a form cross domain will send cookies.

Re: Stop using JSON Web Tokens for user sessions

#56

Post by roetlich »

The general idea of the blog post is correct, but so many things are worded in slightly incorrect ways. I think this blog post needs a few edits.

> JSON Web tokens (JWTs) for session handling instead of cookies.

JWT and cookies aren't mutually exclusive, you can put a jwt in a cookie, unless it's too big. There are two issues: Where do you store a sessions key, and how you create the session key. The author correctly argues that the session key should be stored in a cookie, but doesn't make any arguments against JWTs, as far as I can tell.

> This approach is insecure because essential flags like HTTPOnly are not supported.

This wording is odd, because it's the other way around? It's not that HTTPOnly isn't supported when storing the session key in js, but that HTTPOnly enforces that you don't do it in js.

> the logout function often merely overwrites the JWT on the client side, leaving user sessions valid until timeout.

That's obviously bad, but there are also people who just set a different cookie, without making the previous session cookie invalid.

Then the author goes on to explain a possible XSS attack, but fails to mention that in the example XSS would also be very bad without the vulnerable session key. The injected js could do something evil right away, without steeling the session key. (But yes, it's worse with the session key exposed)

The author doesn't mention the relatively common flow of using refresh tokens together with short lived session keys.

Overall, I think this article can be misleading. A confused beginner could read this article and misinterpret it to mean that protocols like OAuth or OpenID Connect are insecure, just because they use JWTs in some places.

Re: Stop using JSON Web Tokens for user sessions

#57

Post by porridgeraisin »

Just store it in localStorage...

It is just fine.

If anyone is allowed to inject javascript in your site, samesite=lax httponly cookies aren't gonna help much either.. the attacker can fetch /api/me/delete with credentials: include (just like you would have to do in your js code) and it's game over.

And extensions can access httpOnly cookies as well. Not to mention other applications can simply access the plain sqlite db.

So really, just use local storage for tokens.

This way, if you want to expire sessions via refresh tokens, you can simply layer it on top of this, by setting a refresh token in a cookie and adding some extra logic to the api calls.

Re: Stop using JSON Web Tokens for user sessions

#59

Post by sam_lowry_ »

andybak wrote: post #15
embik wrote: post #11

It would be helpful if the post not only told you what to _not_ do (especially when it is a frequently done thing) but offered any sort of alternative.

Cookie based session logins like everyone used to use?

I work for ab EU government, and cookies are a no-go because of cookies directive, so we use JWT and auth the javscript engine, not the browser.

This leads to a multitude if problems, but who cares?

Post reply on HN