How to understand the relationship between Id, Access and Refresh tokens
Hello, we are trying to track down an issue with our app where users appear to be logged out after an hour of inactivity. I say "appear" since I don't believe they are actually being logged out, but rather there is a mismatch with token refreshing.
FWIW we are using the Kinde default expiry values
ID token 3600
Access token 86400
Refresh token 1296000
We are using the Kinde JavaScript client @kinde-oss/kinde-auth-pkce-js
Since the ID token has the shortest TTL what triggers its refresh? I assume one of the Kinde client methods must do that and does the refresh happen within the client or does it trigger an outbound call to Kinde to obtain the new token?
We are more familiar with Access and Refresh token behaviour than ID. Is the Access token refreshed if it falls within the Refresh TTL when we make a call to
Is there a sequence diagram that illustrates the relationship and activity of the three tokens?
FWIW we are using the Kinde default expiry values
ID token 3600
Access token 86400
Refresh token 1296000
We are using the Kinde JavaScript client @kinde-oss/kinde-auth-pkce-js
Since the ID token has the shortest TTL what triggers its refresh? I assume one of the Kinde client methods must do that and does the refresh happen within the client or does it trigger an outbound call to Kinde to obtain the new token?
We are more familiar with Access and Refresh token behaviour than ID. Is the Access token refreshed if it falls within the Refresh TTL when we make a call to
getUserProfile() which travels over the web. Our understanding is that getUser() returns similar information but from within the client and not by going across the network to check directly with the Kinde server.Is there a sequence diagram that illustrates the relationship and activity of the three tokens?
