Hello , I am using the thirdpartypasswordless recipe for backend and hosted the supertokens core using helm-chart with following config snippet [ref : https://github.com/supertokens/supertokens-docker-postgresql/tree/master/helm-chart ] __________________________ # -- Time in seconds for how long an access token is valid for accessTokenValidity: 604800 # -- If true, allows for immediate revocation of any access token. Keep in mind that setting this to true will result in a db query for each API call that requires authentication. accessTokenBlacklisting: false # -- If this is set to true, the JWT (access token) signing key will change every fixed interval of time. accessTokenSigningKeyDynamic: true # -- Time in hours for how frequently the JWT (access token) signing key will change. This value only makes sense if "accessTokenSigningKeyDynamic" is true. accessTokenSigningKeyUpdateInterval: 168 # -- Time in mins for how long a refresh token is valid for. refreshTokenValidity: 1209600 # -- Time in milli-seconds for how long a password reset token is valid for. passwordResetTokenLifetime: 3600000 ______________________________________ Now, on successful signin, the session is created but its expiry is way too long (~2 years) in the DB row of session_info table against the corresponding session handle, however, I have intended to set the expiry to 604800 seconds (7 seconds) as mentioned in the helm-chart values note that on decoding the sAccessToken on online jwt decoder for the same session handle, it gives the expiry timestamp of 7 days from creation however in code, this statement: expiryTimestamp, err := sessionContainer.GetExpiry() is returning the expiry timestamp of about 2 years from now, which is same as the DB entry in session_info table

hey!

okay, then why on JWT decode, the 'expiry' is 604800 seconds (~7days) from now?

cause thats the value you have set for the access token's lifetime

got it! thanks for clarification and prompt response 🙌

yes.

okay