[donatj]

The problem isn’t so much JWTs for auth, it’s just where you are storing them.

The answer here is just to store your session JWTs in HttpOnly secure cookies, something we’ve done for years.

It honesty simplifies everything anyway. The client has no need to see it or manipulate it. The client code just watches to see if its requests come back as unauthorized and boops you into the authorization process if you are. No need to manually append any sort of auth onto any request. The cookie jar does it for you automatically. It’s really how you should be doing it already.

Only real hitch is you can’t cross domain barriers, but that’s not insurmountable. Couple ways to handle it, we generally prefer a little handshake process and a separate JWT per domain. That said, we try to keep everything on subdomains and set the cookie for .example.com

[uticus]

Agreed. If security needs to extend past domain, you are not using the web in the way the web supports.

I appreciate interesting solutions that bend the rules of the underlying technology, but (1) the web needs to be treated as if it is what it actually is, and (2) papering over the parts that cause pain is not helping anything.

[marcosdumay]

> The answer here is just to store your session JWTs in HttpOnly secure cookies

And set CORS correctly (probably by not having anything in it), and deal with CSRF, and make sure you don't have any XSS issue.

It's definitively not insurmountable. But the XSS problem the article focus on still applies. (You shouldn't have any problem with XSS anyway, it's a solved problem that most of the times shouldn't even require thinking about it to keep it solved.)