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.
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.