3 ms·
I think you're conflating something here. Whether you send a session ID in a cookie or a JWT makes no difference for the app's general behavior, even when you u
by WA 2y ago
I think you're conflating something here. Whether you send a session ID in a cookie or a JWT makes no difference for the app's general behavior, even when you use multiple tabs or multiple devices.
But I remember a time when especially bank websites added an additional token (like a super strict CSRF token) to their app, which tracked the current page of a user and if you browsed the same website from another tab, this other tab didn't have the proper token and the whole thing just returned "invalid user action" or something like that.
However, this has nothing to do with session cookies.
- tjansen 2y agoTypically, in the Weblogic days, session cookies were used to hold a server-side session containing the app state. If you just hold auth data in the session this is not a problem. But if hold state like form data in the session it becomes a huge source of errors. Virtually all non-trivial web-based applications had these issues 20 years ago (before „Ajax“). J2EE servers like Weblogic even supported stateful EJBs that brought server-side state to a new (insane) level. While you could theoretically use JWTs for the same purpose, they are typically only used for authentication. And back then JWT wasn’t a thing.
- sam_lowry_ 2y ago> Whether you send a session ID in a cookie or a JWT makes no difference for the app's general behavior It does make a difference. The cookie is sent by the browser to the server, the JWT is sent in the Authorization: header by the JavaScript code executed by the browser. Using an opaque JWT token wrapped in cookie is OK. Using a JWT token in the Authorization: header is not OK.