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. 
@jmangelo Any updates on this?
An update on this very important topic would be appreciate. It should be MUCH more flexible how we as users want to configure the access token lifetime.
Hey there @alexab
Let me circle back with our product team to see what’s the status on that. I’ll get back to you as sson as I have any updates!
Hey @alexab!
The only info I managed to get is that our product team is aware of the request and that we are working on a solution. For now I’m not able to disclose any dates or provide further info on that.
Hi @konrad.sopala → that’s awesome news! Thank you for checking with the product team. Now we will just hope that it’s this year 
If I get to know anything more any time in the future, I’ll let you know in this thread!
Just wanted to +10 on this (as I have before)
…and to let auth0 know this is one of the most voiced issues regarding auth0 within some SPA communities (e.g. JAM stack and Vue fans). The 3 day inactivity restriction was voiced already in 2017 and it’s sad to see that no actions have been taken thus far - simply vague promises of a brighter future. I’ve read from different threads (@bragma being included in many of them) that auth0 is holding out for a “quick fix” since it doesn’t align with the long-term plans.
It’s just sad that those long-term plans have to be achieved through disappointing your current users.
I do apologise for my bickering and I am aware of some suggested workaround (ie create a back-end for the potentially static SPA), but as @bragma has pointed out numerous times - it shouldn’t be the service’s consumer’s job to fill the gaps/pick up the slack of said service.
Hey there @ajv!
We as a developer community team in terms of such cases are your advocates to relay the constructive feedback you provide to appropriate engineering or product teams to get such fixes deployed or at least communicated what will happen further.
We’re doing our best in advocating for your needs but you need to keep in mind that possibly it’s not the only thing that disrupt our community developers work now. Our teams need to highly prioritize what they need to introduce or fix in order to help the biggest group of developer at certain moment.
I’m totally sorry for any inconvenience that you need to face but for now the only thing that we as developer community team can do is to constantly emphasize your needs and potentially get back with the info from our teams. We’re really doing our best in making your developer experience better!
I really appreciate constant feedback you share with us that I can relay to our product team and I’m once more terribly sorry that you need to face such struggles for now!
Hi @ajv
after 1+ years working on a product using auth0, I have to say that the negative impact on my customers has been lower than expected. Browsers saving and sharing user credentials over different devices mitigated it I think.
Still, over years I’ve seen Auth0 move from a mostly token based solution to a mixed cookie/token, universal login page, silent auth, etc. Cookies are used for those nifty solutions and I honestly think it may be time to allow longer cookie expiration times.
Overall, what I thought might have been a major drawback is now much lower in my list of priority requests. Facts prove that customers can live with it and are engaged enough to not have to login every few days.
Thanks a lot for the feedback and overview of your thing! I’ll try to also amplify it to appropriate teams!
Thanks for the update @konrad.sopala! This is a significant issue for me as it has caused opposition to my decision to go passwordless. People objected to passwordless as too burdensome and slow. But, my response was that it’s no big deal, you’d only have to do it once per device and you’d stay logged in as long as you used our product at least once a year. But, without this feature that is not possible.
I understand that there are other competing priorities, but I’d like to see 2 things:
I think that will help create more transparency.
Thanks!
Hey @adamzr!
Thanks for reaching out with your thoughts!
In terms of bullet points I do agree that those are perfect value propositions highlighting transparency and we do evaluate them such options.
Thanks for putting +1 to it!
The public roadmap would be the best!
Hey!
As far as I know we do have plans for public roadmap it’s been actively evaluated but for know I cannot disclose any ETA.