I guess here are my overall thoughts on the subject: XSS (where an attacker can execute JS on your site) is one of the OWASP Top 10 most common exploits for a long time now. It's far more common that desktop or server compromise by a massive factor.
Because of this, I tend to dislike relying on browser storage (local storage or whatever) to store sensitive data. Part of the reason why is that if you have a token in local storage an attacker can compromise it and send it off to whatever API they run to harvest your data.
Attackers can then remotely performing attacks against your service impersonating a user, OR, if they want, they can simply fire off requests from the browser using the JWT against your backend service and still cause problems.
Compare this to the alternate scenario: if your session is managed via an httpOnly cookie. In this case, even if an attacker can gain JS access they can only make authenticated requests against your site while the user is ON THE SITE doing stuff. They won't have access to a token they can harvest which they can use while you (the user) are offline or whatever.
Because of this, the latter option is a lot nicer to me in terms of web security. But, again, like everything in the security world: context matters.
If you're building simple sites where there isn't a lot of super important data/etc., and you really like using tokens (even though it's far simpler to use httpOnly cookies in just about every web framework) -- go for it :o
I watched your video. You are certainly right about cookies being the more secure storage option. It's just too bad that the constraints on cookies make them hard to use universally, especially for stateless purposes.
You are missing a very large point about scalability of sessions vs stateless. Your argument is basically "sessions are easy to scale". You are right in that it has been done and is understood. But the argument for stateless is "there is nothing to scale". There is no extra DB (with an external provider), no added request latency, no caches to invalidate, etc. A lot of overhead and operational complexity is just gone.
However, there is a trade-off for how "instant" your security changes take effect. For stateless, changes won't take effect until the token expires. If it is critical for your app that security changes are immediate, then there is no benefit to going "stateless"... it will end up with at least the same level of complication as session based but with less benefit. IOW, looking up a blacklist from DB on every request has no different overhead from just looking up user permissions on every request, but the latter has more capabilities (seeing security changes, not just token invalidation). Note that introducing caching into session-based security throws away the immediacy advantage too!
Since you work in security, it makes perfect sense that you see sessions as the best possible implementation. But for many apps, "instant changes" will have little real benefit to the app while the session infrastructure will still eat non-trivial ops budget.
Also for "JWT and mobile", in your video you only mentioned mobile browsers. But I doubt that is the point that people are trying to get across when they say that, since as you said, mobile and desktop browsers aren't that different. The point is that native apps probably don't have built-in automatic cookie storage and retransmission, origin tracking, protected header enforcement, etc. (all the things that make it easier in browsers). So the "cookies are easier" rule doesn't really follow. You could still send them, of course, but it is just as easy to send an Authorization header as a Cookie header, and a lot of people like working with JSON better than form-encoded data (for the stateless case anyway... for sessions you never look at data so it doesn't matter much).
In summary, you are not wrong about what is most secure. But everything is a trade-off. And sometimes trading in some security features (like stateless instead of instant security changes) can gain large benefits in other areas.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Heyo! Great comment.
I guess here are my overall thoughts on the subject: XSS (where an attacker can execute JS on your site) is one of the OWASP Top 10 most common exploits for a long time now. It's far more common that desktop or server compromise by a massive factor.
Because of this, I tend to dislike relying on browser storage (local storage or whatever) to store sensitive data. Part of the reason why is that if you have a token in local storage an attacker can compromise it and send it off to whatever API they run to harvest your data.
Attackers can then remotely performing attacks against your service impersonating a user, OR, if they want, they can simply fire off requests from the browser using the JWT against your backend service and still cause problems.
Compare this to the alternate scenario: if your session is managed via an httpOnly cookie. In this case, even if an attacker can gain JS access they can only make authenticated requests against your site while the user is ON THE SITE doing stuff. They won't have access to a token they can harvest which they can use while you (the user) are offline or whatever.
Because of this, the latter option is a lot nicer to me in terms of web security. But, again, like everything in the security world: context matters.
If you're building simple sites where there isn't a lot of super important data/etc., and you really like using tokens (even though it's far simpler to use httpOnly cookies in just about every web framework) -- go for it :o
I watched your video. You are certainly right about cookies being the more secure storage option. It's just too bad that the constraints on cookies make them hard to use universally, especially for stateless purposes.
You are missing a very large point about scalability of sessions vs stateless. Your argument is basically "sessions are easy to scale". You are right in that it has been done and is understood. But the argument for stateless is "there is nothing to scale". There is no extra DB (with an external provider), no added request latency, no caches to invalidate, etc. A lot of overhead and operational complexity is just gone.
However, there is a trade-off for how "instant" your security changes take effect. For stateless, changes won't take effect until the token expires. If it is critical for your app that security changes are immediate, then there is no benefit to going "stateless"... it will end up with at least the same level of complication as session based but with less benefit. IOW, looking up a blacklist from DB on every request has no different overhead from just looking up user permissions on every request, but the latter has more capabilities (seeing security changes, not just token invalidation). Note that introducing caching into session-based security throws away the immediacy advantage too!
Since you work in security, it makes perfect sense that you see sessions as the best possible implementation. But for many apps, "instant changes" will have little real benefit to the app while the session infrastructure will still eat non-trivial ops budget.
Also for "JWT and mobile", in your video you only mentioned mobile browsers. But I doubt that is the point that people are trying to get across when they say that, since as you said, mobile and desktop browsers aren't that different. The point is that native apps probably don't have built-in automatic cookie storage and retransmission, origin tracking, protected header enforcement, etc. (all the things that make it easier in browsers). So the "cookies are easier" rule doesn't really follow. You could still send them, of course, but it is just as easy to send an Authorization header as a Cookie header, and a lot of people like working with JSON better than form-encoded data (for the stateless case anyway... for sessions you never look at data so it doesn't matter much).
In summary, you are not wrong about what is most secure. But everything is a trade-off. And sometimes trading in some security features (like stateless instead of instant security changes) can gain large benefits in other areas.