Pardon me if I have already presented the problem in other forms and questions but I am really trying to work around this. I have a client/api setup on Auth0 and using the new implicit flow. I can renew tokens using
renewAuthwhich I have implemented and got rid of refresh tokens in my web app. The problem is that there is a time limit on
renewAuth, which seems to be tied to the SSO cookie.
I need my users to be able to renew api tokens for a very long time, without bugging them with a login page. Currently it seems I can’t do it for more than 30 days, and what’s worse they have to login again if they don’t use my app within 3 days. I can somehow set the 1st parameter from the dashboard, but not the second.
This is unacceptable for my users and is creating a problem with my company in using Auth0. What I need is the same user experience provided by many sites, implicitly or with the “remember me/keep me logged in” flag.
As it is, the new
renewAuth flow is not a replacement for refresh token functionality. I really need this to be solved out, Auth0 please help with any suggestion/solution.
Notice that allowing (even via api, dashboard is not important) to change the 2 involved parameters (SSO session max timeout and 3 days inactivity) and change their current limits would solve my problem.
I provided an extended answer at your other question in terms of how could it be feasible to handle your overall requirements.
In relation to the two SSO session related timeout values I can let you know that although the idle timeout session is currently not configured this is something we may consider and I submitted this idea on your behalf. I can’t however provide any indication on the final outcome or timeline.
Thanks. I sort of double posted, so I’ll comment on the other answer. I think my use case can easily be covered by allowing me to change those 2 values as I need, nothing more.
Hey @jmangelo, just want to see if I’m still following best practice based on this answer.
It’s my understanding for my React SPA the expectation is that if a user is idle for 3 days, renewAuth will return login_required and they’ll have to login again because this timeout is not configurable. Is that correct or is this idle timeframe now configurable? I think this makes it pretty tough for a SPA where I imagine most users are probably more used to a 30-day timeout regardless of idle or not.
@jmangelo , @matthew.isabel,
I truly hope something is changing here. Months have passed after my request and my issue is still open. While I understand maybe it’s not a top priority, I consider it to be easy enough for a quick change to be considered. I have the same problem with my SPA and I don’t like the proposed solution of having to implement sessions myself. The idea is to pay for a service to avoid making things yourself. Auth0 already has everything done, they must only allow some configuration there. At least an update would be nice.
@mbraga I understand that this does not look good because if there’s already one setting for total lifetime how hard it would be to have another. However, the information I have is that we may want to provide something completely different then just a value setting, for example, a way to define a policy that would evaluate when the session could be reused or considered no longer valid. The side-effect of being more flexible is that it will require more time and meanwhile if just another setting was available it would be another thing that in future could require a migration.
@matthew.isabel your understanding is correct and the three days is currently not configurable; see my other comment for some additional information.
@jmangelo a more configurable system is always better, so it’s ok to aim high. But as a developer, I know that sometimes pointing at the best means long waits and for the end user having nothing for a long time, so please consider well pros/cons and migration costs for this.
Having no insights on Auth0’s priorities or roadmaps may mean waiting for long or forever, who knows? Having a rough time frame for this would be really useful.