[MaxBarraclough]

Depending on exactly what we're doing, we can work around this with crypto, right?

A token can securely prove that it was issued by the server/service, and under what conditions, without the server/service statefully tracking the token after issuing it.

I know I'm not the first to think of this, but I'm not sure how widely used this sort of technique is in practice.

[AmericanChopper]

That’s exactly how authentication JWTs work. They work differently from CSRF tokens though, because the CSRF token is generated for each request, not each ‘session’ (so you need much more complex server-side state management). But that said CSRF isn’t particularly relevant if you’re using a JWT in the Authorization header. CSRF attacks the fact that browsers will use cookies to automatically authenticate requests. If you’re not using cookies for authentication, and adding a JWT to the headers instead, then that automatic authentication doesn’t occur. Correct me if I’m wrong, but I’m not aware of any CSRF attack that targets Authorization headers, I believe any attack that does is just an XSS.

[exelib]

Well, where you store your JWT on the client? LocalStorage? Then you have probably much broader surface for an attacker.

In case of XSS you lost anyway. But with HttpOnly-Cookies the attacker can't steal your token and do everything from everywhere with your token.

[AmericanChopper]

XSS is a problem you have to solve no matter where you store your authentication material. If you have an XSS, then an attacker can do anything they want on your web pages. I’m not sure you’re gaining anything by saying “anything but steal the auth token”. If you store it as a cookie, now you have to solve XSS and CSRF, so I’d say that makes your attack surface broader. Especially considering front end frameworks have become very good at preventing XSS, and can’t do anything about CSRF.