this post was submitted on 02 Jul 2023
577 points (95.9% liked)
Showerthoughts
29325 readers
4 users here now
A "Showerthought" is a simple term used to describe the thoughts that pop into your head while you're doing everyday things like taking a shower, driving, or just daydreaming. The best ones are thoughts that many people can relate to and they find something funny or interesting in regular stuff.
Rules
- All posts must be showerthoughts
- The entire showerthought must be in the title
- Posts must be original/unique
- Be good to others - no bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia
- Adhere to Lemmy's Code of Conduct
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This is false.
Lemmy's JWTs are forever tokens that do not expire. They do not have any expiration time. Here is the line of code where they disable JWT expiration verification.
Lemmy's JWTs are sent via a cookie and via a URL parameter. Pop open your browser console and look at it.
There is no way to revoke individual sessions other than changing your password.
If you are using a JWT cookie validation does not matter, you need to have robust JWT validation. Meaning JWTs should have short expiration times (~1hr), should be refreshed regularly, and should be sent in the header.
When I said, "it validates the timestamp" I wasn't talking about the JWT
exp
claim (which you're correct in pointing out that Lemmy doesn't use). I was talking about how JWT works: The signature is generated from the concatenation of the content of the message which includes theiat
(Issued-at) timestamp. The fact that the timestamp is never updated after the user logs in is neither here nor there... You can't modify the JWT message (including theiat
timestamp) in Lemmy's cookie without having it fail validation. So what I said is true.The JWTs don't have an expiration time but the cookie does... It's set to one year which I believe is the default for
actix-web
. I'm surprised that's not configurable.You actually can invalidate a user's session by forcibly setting their
validator_time
in the database to some date before their last password reset but that's not really ideal. Lemmy is still new so I can't really hold it against the devs for not adding a GUI feature to forcibly invalidate a user's sessions (e.g. in the event their cookie was stolen).I also don't like this statement of yours:
Cookie validation does matter. It matters a lot! Real-world example: You're using middleware (or an application firewall, load balancer, or similar) that inserts extra stuff into the cookie that has nothing at all to do with your JWT payload. Stuff like that may require that your application verify (or completely ignore) all sorts of things outside of the JWT that exist within the cookie.
Also, using a short expiration time in an app like Lemmy doesn't make sense; it would be super user-unfriendly. The user would be asked to re-login basically every time they tried to visit a Lemmy instance if they hadn't used it in . Remember: This isn't for message passing it's for end user session tracking. It's an entirely different use case than your typical JWT stuff where one service is talking with another.
In this case Lemmy can definitely do better:
When using JWT inside of a cookie (which was not what JWT was meant for if we're being honest) there's really no point to using the
exp
claim since the cookie itself has its own expiration time. So I agree with the Lemmy dev's decision here; it'd just be pointless redundant data being sent with every single request.Now let me rant about a JWT pet peeve of mine: It should not require Base64 encoding! OMFG talk about pointless wastes of resources! There's only one reason why JWT was defined to require Base64 encoding: So it could be passed through the
Authorization
header in an HTTP request (because JSON allows characters that HTTP headers do not). Yet JWT's use case goes far beyond being used in HTTP headers. For example, if you're passing JWTs over a WebSocket why the fuck would you bother with Base64 encoding? It's just a pointless extra step (and adds unnecessary bytes)! Anyway...