Closed ashvin27 closed 1 year ago
why?
Because a token cannot be extended beyond the Refresh TTL. After a refresh, the new token retains the IAT of the very first token. This means that after the expiry of the Refresh TTL of the first generated token, the user still has to log in again.
Because a token cannot be extended beyond the Refresh TTL. After a refresh, the new token retains the IAT of the very first token. This means that after the expiry of the Refresh TTL of the first generated token, the user still has to log in again.
Okay, I see in the JWT specs that this is how the refresh TTL is supposed to work.
I don't really follow why it would cause the user to have to log in again, we use this package without that problem.
If you wanted a custom set of claims, you can do that too already?
The problem is, that after the refresh the new token get's the iat
from the old token. So if your Refresh TTL is 2 weeks your users have to login again with their credentials. The iat
is not rolling with the last refresh but nailed to the very first token.
Example:
TTL = 60min Refresh TTL = 2 weeks
iat = 2022-12-01 00:00:00
2022-12-13 23:00:00
-> 401 Token expired (TTL expired, refreshable)iat
from the login token because is persistent (2022-12-01 00:00:00
)2022-12-14 00:00:00
-> 401 Token expired (TTL expired)iat
is older than Refresh TTLHere is another article which also addresses the problem in this package
Thanks, everyone for contributing, I've tested here and so far I have got any issues, we're good to merge this update?
Thanks.
@eschricker what are your thoughts about that?
@ashvin27 can you do the requested changes in the comments?
Remove iat(IssuedAt) from persistant claim to resolve refresh token expiration issue
Description
Checklist:
CHANGELOG.md