[szmarczak]

No need to stop. The XSS argument also applies when using cookies.

JWTs are just tokens like session data but in JSON format. What format you choose to go with doesn't matter.

You can keep storing JWTs in local storage and still be secure. Discord removes it on page load and restores it when the tab is closed.

Also if your website is susceptible to XSS, skill issue, exactly like in the case of SQL injections. That wouldn't have happened had people used the right tools and not played with fire.

[wccrawford]

I think anything can be abused, and too many people don't have a security-first mindset.

One of the advantages of JWTs is that you don't have to check your database or filesystem to make sure the the user is valid and logged in. All that data is in the JWT. If it's just a static page, it doesn't need to hit any data.

The problem then comes that some developers think that makes it secure, and don't check the database for revocation before doing anything with the account. Especially not for giving out private data. They might check before changing any data.

I think it's a really neat idea that is far too easy to mishandle and create a bad situation. It can save a lot of bandwidth and CPU cycles if you have a lot of non-interactive pages and all you need to know is whether to show that the user is logged in or not. But for actually doing anything, it's practically no better than a session cookie, and it's got a lot of foot-guns.

[dariosalvi78]

with cookies you can restrict them to HttpOnly so that they are not exposed to client-side scripts. This reduces the chances of XSS to access the long-lived access tokens (JWT or session ids).

[littlecranky67]

This. I store my JWT in a cookie, and the cookie is of course set to HttpOnly,Secure and SameSite=strict. That basically kills XSS. I do not use openid connect, and one of my pet peeves with OIDC is that the access/refresh tokens are always exposed to the JS side (not in a cookie using HttpOnly) in any impl. i've seen.