Description
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.