expire_jwt_at should not be on the db record but on the jwt. #18

tbem · 2025-04-24T18:00:23Z

I was exploring how to set up expire_jwt_at and was surprised to see that the expiration is managed at the record level in the database.

This approach has a key drawback: when a user logs in from multiple devices, each new token overwrites the previous expire_jwt_at.

We could define a token lifetime as a constant (e.g., JWT_EXPIRATION_TIME) and encode the expiration (exp) directly inside the token payload at generation time.

This way:
• Expiration is self-contained in the token (no DB lookup required)
• Multiple sessions per user/device can coexist safely
• Token validation uses standard exp verification during decode

Another feature I would like to see is the refresh_token.
There is no refresh_token available. This way we don't offer a way of extend user sessions in a more secure way. We could keep access_token with a low expiration_time and have a refresh_token with expiration_time of 30d for example.

stas · 2025-05-06T15:23:21Z

Thanks @tbem

could you confirm you don't mean

OTP::JWT::Token.jwt_lifetime = 60 * 60 * 24

when you're discussing the token "expiration" ?

The db record is used to force a token expiration at the DB level, eg. in case an user access was suspended

expire_jwt_at: of type datetime, optional and used to force a token to expire

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

expire_jwt_at should not be on the db record but on the jwt. #18

expire_jwt_at should not be on the db record but on the jwt. #18

expire_jwt_at should not be on the db record but on the jwt. #18

expire_jwt_at should not be on the db record but on the jwt. #18

Comments