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 the iat (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 the iat 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:

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.

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 <some time shorter than an hour like you suggested>. 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:

• Give end users the ability to invalidate all logged in sessions without forcing a password reset.
• Make the cookie expiration time configurable.

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…