Auth0 Home Blog Docs

How to do long expiration time with passwordless?



I’d like my users to not have to see the login page if they have logged in on that device for the past year. However, right now the login time seems to be limited by the value in the field “Token Expiration For Browser Flows (Seconds)” under APIs for the API that I am using. That field won’t accept values longer than 24 hours.

I am using the hosted login page for my Angular2 SPA. Right now I am using username/password, but I intend to switch to passwordless.

How can I keep users logged in?


Given that you’re using the hosted login page the fact that you plan to switch from username/password to passwordless is mostly irrelevant as the end result is that a session is established at the identity provider (your Auth0 tenant/domain) and tokens are issued to the client application.

For a browser-based application the issued tokens should be relatively short in lifetime given the browser environment is a very hostile one and the chances of tokens leaking are greater. However, your browser-based application can leverage the session that was established in the identity provider to obtain new tokens without forcing the user to actively authenticate again (see the checkSession method in Auth0.js library).

Using that approach you will be able to obtain new tokens until that session exists; at this time this means it will last until the maximum lifetime configured for the session is reached (defaults to seven days, but you can configure it through SSO Cookie Timeout field in your tenant advanced settings) or the user is inactive for three days (the inactivity timeout is currently not configurable) or the user terminates the session (would happen if the logout in your application also triggers logout in Auth0).

In conclusion, with checkSession and SSO Cookie Timeout you may have some additional flexibility that gets you closer to your requirements, but the non-configurable inactivity timeout may still be an issue. I can let you know that there are plans to give you more control and flexibility over the session in question which would likely meet all your requirements, but at this time there is not yet definitive information about this.


Thanks @jmangelo ! That is very helpful. I’ll add in support for checkSession. The 3 day inactivity timeout is very unfortunate. I am happy to hear that there are plans to fix that. Is this something that I can expect within the next year or so?


I’m also waiting for this. The 3 day inactivity is way too strict for my use case. A rough time frame would be really welcome. Thanks!


As @mbraga can confirm he’s also been eager to have more control over the use of the session and it’s been a while since I remember discussing this with him. Given we are in January I’m almost tempted to say that yes, within this next year, but the truth is that like I mentioned before I don’t have any definitive date.


Thanks @jmangelo , I’ve made up my mind that you are delaying this so much because you are building something bigger related to session management. Too bad I didn’t find anything in the published roadmap and I wasn’t able to relate this to any specific upcoming feature, so I could at least have some hope in the expected time frame.
What really puzzles me is that longer sessions seems to be fairly common in websites, still I have not found many complaints here regarding actual limits. :slight_smile:


@jmangelo Any updates on this?