Remove issued at from persistant claims

[ashvin27]

Remove iat(IssuedAt) from persistant claim to resolve refresh token expiration issue

Description

Checklist:

• I've added tests for my changes or tests are not applicable
• I've changed documentations or changes are not required
• I've added my changes to CHANGELOG.md

[mfn]

why?

[jansgescheit]

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.

[jansgescheit]

For backwards compatibility, iat should be included in the persistent_claims config and marked as Breaking Change accordingly

[Messhias]

@jansgescheit one question: can we add the iat in $persistentClaims conditionally if it exists on payload?

In that way, it'll not crash if someone wants to use a custom one.

[jansgescheit]

For my understanding, the iat is always included in the payload. Therefore, not much will be achieved here.

[Messhias]

So we cannot just remove it right? On that case should be additionally added with a if condition if for some reason the user doesn't want to have it in persist claims.

[jansgescheit]

That would make sense to avoid a breaking change. Perhaps via a configuration switch with a denylist for filtering

[Messhias]

Ok, so let's add the if to it for that we can merge it.

Thanks

[jansgescheit]

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.

[specialtactics]

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?

[jansgescheit]

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

• Login -> Token with iat = 2022-12-01 00:00:00
• Api Call at 2022-12-13 23:00:00 -> 401 Token expired (TTL expired, refreshable)
• Refresh Call -> new Token with iat from the login token because is persistent (2022-12-01 00:00:00)
• Api Call at 2022-12-14 00:00:00 -> 401 Token expired (TTL expired)
• Refresh Call -> "422 Token has expired and can no longer be refreshed", because iat is older than Refresh TTL
• User has to Login again with their credentials

[jansgescheit]

Here is another article which also addresses the problem in this package

[Messhias]

Thanks, everyone for contributing, I've tested here and so far I have got any issues, we're good to merge this update?

Thanks.

[Messhias]

@eschricker what are your thoughts about that?

[Messhias]

@ashvin27 can you do the requested changes in the comments?