| > There are alternatives to JWT which work on the same principle My general position is that JWTs are not well-suited or designed for web app session management, full stop. There are direct alternatives to JWTs like PASETO and Macaroons, and I don't think those are suited for session management either (though in general they are better designed from a security and simplicity perspective). > RoR's default is in fact its own custom implementation of a similar mechanism but with encryption instead of just signatures That's pretty much correct, with the caveat that you don't need to add a bunch of machinery with footguns galore on the frontend and backend just to be able to parse them. And as I pointed out in our last discussion, this has been the default session storage mechanism in Rails since years before JWTs existed. > I prefer using JWT HS256 which is fast/cheap compared to full encryption This feels like like bike-shedding for all but the largest of apps. > I try to keep my signed data light, especially if it has to be sent over the wire frequently. Yes, this is a recommendation for Rails' default session mechanism as well, since most browsers impose a fairly small size limit on cookies (4KiB IIRC). > I find the JWT approach more minimalist; it's only for determining account ID and privilege level, nothing else and it doesn't have to be secret. I feel like storing anything more than the bare minimum required to determine access to resources is overkill. There are a lot of other use cases for session data, especially if you're using a full-stack web framework vs. a SPA with a separate backend (I have strong opinions on this as well, but that's a different discussion). For example, Rails has the concept of a "flash" where you can display temporary, ephemeral messages to the user. These are stored in the session, consumed on the next request the browser makes, and then removed. |