Refresh token renewal

While the library handles Access Token refreshing with silent renew, it doesn’t take into account the Refresh Token expiration time at refresh_expires_in. https://github.com/authts/oidc-client-ts/blob/8d8a700b23a2fffdada0b3ecaf271bc16a74759d/src/UserManager.ts#L226-L232

Assuming the user either sets automaticSilentRenew or uses events to do the same, this forces a constant Access Token refresh cycle when Refresh Token expiration time is less than accessTokenExpiringNotificationTimeInSeconds, since Access Token expiration time is limited by the Refresh Token expiration time.

[Badisi]

I once reported the same issue with the previous library version (different scenario though) : oidc-client-js#948

Issue is still relevant with oidc-client-ts and @atomicbrainman’s proposal to fix it seems the way to go.

[atomicbrainman]

@longsleep

refresh_expires_in is unsupported and afaict also non-standard. What providers/services do support it at the moment?

It seems at least Keycloak does support it, I don’t know about the others.
And actually, we don’t need it to detect a session that is bound to expire soon.

Also, there are no errors when refreshing the token.
Let’s use an example to clarify the issue:

Say, we have an auth server with the following setup:

• Session time set to 12 hours (Refresh Token time)
• Access Token expiration time is set to 20 minutes

And the user:

• Has an existing session that expires in 22 minutes
• Has an expired Access Token, but a valid Refresh Token
• Client is configured with automaticSilentRenew: true and accessTokenExpiringNotificationTimeInSeconds: 60

The client does the following:

1. [Time passed: 0] Automatic silent renew successfully requests a new Access Token. It’s expiration time is 20 minutes.
2. [Time passed: 19 minutes] Again, automatic silent renew successfully requests a new Access Token. But it’s expiration time is 3 minutes, same as the time left before Refresh Token expires.
3. [Time passed: 21 minutes] Access Token is about to expire again. So automatic silent renew successfully requests a new Access Token. It’s expiration time is 59 seconds.
4. [Time passed: 21 minutes 1 second] Automatic silent renew goes into a cycle of successful requests to refresh the Access Token. But the returned Access Token has an expiration time of less than 1 minute, so the next request is fired almost immediately after the previous one finishes.
5. [Time passed: 22 minutes] Automatic silent renew finally fails to renew the token and the client raises a logout event.

Step 4 is the issue here. On step 3 we can detect that the returned Access Token has an expiration time less than what is set in accessTokenExpiringNotificationTimeInSeconds and do something to prevent step 4, e.g. logout the user immediately.

A simple way to reproduce the issue would be to setup your client with a very large accessTokenExpiringNotificationTimeInSeconds, e.g. set it to 1000000