right - so the
Token Lifetime value is set as a max of 86400 and so the browser token expires after 24h. I believe you can use
CheckSession() to keep the token alive
right - so the
The requirement I was asked to implement is to be able to return to a session over the course of a week from browser that may have been inactive for several days without having to log back in (the JWT is stored in LocalStorage), so I don’t think CheckSession will work in this case… My understanding is that it requires a currently-valid token and an active session: https://auth0.com/docs/libraries/auth0js/v9#using-checksession-to-acquire-new-tokens
At this time an authentication session at the Auth0 service (one that can be leveraged by
checkSession) will last until the maximum lifetime is reached (configured through SSO Cookie Timeout setting in the advanced tenant settings) or the maximum inactivity time out is reached (currently set to three days and non-configurable).
In addition, and as you experienced the Token Expiration For Browser Flows (Seconds) has a hard limit of 86400 (24 hours); the maximum allowed can be less depending on how Token Expiration (Seconds) is set, but it can never be greater than 86400.
Taking in consideration the limit in the token expiration and the non-configurable inactivity timeout on the session it’s currently not possible to guarantee the requirement that a SPA is able to maintain an active local session through a complete week without asking the user to login again. It may be possible if the user is active every other day, but this is not guaranteed. I know there’s planned work on giving more control over the authentication session at the Auth0 service which could make the current inactivity timeout irrelevant and then allow the use of
checkSession to meet that requirement, but at this time I don’t believe that is possible.
hopefully you do understand that limiting logins to 24h is a HUGE issue and HUGE show-stopper for many of your customers who did NOT have it before April 2018 and only got it after recent upgrades (those upgrades were not optional, and the info about 24h limitation was not in upgrade email, so we had to realize new limitation simply by experiencing it as a bug that turned later on a “feature”).
In regards to token expiration I am currently trying to setup an expiration independently of a fixed timeframe. We would like the token to expire each midnight, no matter when the last login happened. Is this somehow possible?
Is the official Auth0 answer that web session tokens can NEVER have an expiration longer than 24 hours? If so, my entire dev shop may be moving away from using Auth0 on all of our projects.
i have the opposite problem. i noticed the access token returned from oauth/token expires in 1d (86400) but the jwt/id_token expires in 36000. (a subtle gotcha…)
i tried changing Token Expiration to 36k seconds to match the id_token and it doesn’t work. my dashboard says 36k but oauth/token always returns an expires_in that is 86400.
bug? am i setting the wrong place to update the access_token expires? is there a lag in the setting taking effect?
Edit: i guess it’s not so much a gotcha as allowing for the id_token to be refreshed.
Depending on your library, it might also be possible to work around this limitation by ignoring the token expiry time on the client. In C#, for example, you can set TokenValidationParameters.ValidateLifetime = false.
Is there a way to set the expiry on the access token in the Authorization Code Grant Flow through the API?
Unfortunately as far as I can see looking at our API explorer there isn’t a way to set it using the API
ok thank you for getting back to me.
I have seen that this can be done from the auth0 console but is the change there really changing the access_token expiry when using the Authorization Code Grant Flow?
Not sure about that. Can you tell exactly what console are you referring to? Let me check it then and get back to you soon!
in the auth0 Management Api settings page…
I have changed it to last 30 days but users are still being logged out after 24 hrs
This is why I was questioning if maybe changing the access_token when using the Authorization Code Grant Flow does actually change it…
Got it. Thanks for providing that context! Let me dig into it and get back to you with news soon!
and just for extra info this is a native app client using the SDK for implementation and the issue is when calling the CredentialsManager class… logged in status doesn’t persist after 24hrs which why we think the access_token is not really changing
Thank you! Let me try establish the reasoning behind it and get back to you with an answer!
the section we are both looking at is the Auth0 Management API which is a system API and is not meant to be consumed in browser-based flows. You need to create a custom API which will then allow you to update that setting…
Is there any new regarding the ability to keep users logged in for a week or more in a spa scenario?
Any follow up here? It’s been quite frustrating to deal with this on our end. We keep getting customer complaints for this 24h limit.
Any solution for this? Even I too searched a lot for getting the access token valid for 7 days but not able to find any solution…