Hi,
how long can I call renewAuth and expect it to work? Is it related to the SSO timeout settings in the account? If so, it’s 30 days. Too few for me.
My customers expect to NEVER be logged out if they don’t explicitly do it. My previous implementation using a refresh token worked, but now I am switching to renewAuth. If they have to login more than once they’ll kill me.
I and them accept the risk of a very long session, but how can I make it work?
Thanks!
At this moment the 30 days are indeed a hard limit on the session timeout; there’s an already known issue that we are aware and intend to fix that is about the authentication method to get refreshed tokens based on a session is not renewing the idle timeout which could result in failure to get refreshed tokens sooner than the maximum timeout.
However, even the 30 days are not sufficient for your use case so the above fix would not address your concerns. The reality is that at this time only refresh tokens provide with a always lasting mechanism to renew tokens (at least until they are revoked); the unfortunate side-effect of that is that refresh tokens are not really suitable for browser-based applications.
From my perspective if you really need to provide a lifelong login experience I would consider having more than just a browser-based application. Most of the time developers already have a capable web server behind their browser-based applications that is simply not used fully and is mostly used only to serve the static files that will bootstrap the browser-based application. If you’re in a situation that you can easily go beyond just static file serving I would suggest you to consider the use of hybrid flows that could allow the immediate delivery of tokens to the client-side for increased user experience, but could also allow the use of grant types (authorization code) eligible to the use of refresh tokens.
You would then maintain refresh tokens at the server-side that could be used until explicitly revoked. This would imply that you should now maintain your notion of a session between your browser-based application and your server-side which is something regular web applications in general already do after processing the response from the identity provider. In theory you would be able to provide the typical user experience of a browser-based application while leveraging increased flexibility by having a server-side that does something more than just serving static files.
Thanks, I really appreciate the answer. I have a webserver for static SPA + API and I could for sure play in between the user and IdP, but I think that this would really lessen the benefits of having auth0. For what’s worth I could store login+pass and use those to generate tokens, but it does not make much sense. It’s a lot of work for covering a case that Auth0 already suits well, simply I need to fiddle 2 settings. I am expecting Auth0 to be flexible enough to cover all customers needs, providing a service, not more work. The implicit flow + silentAuth perfectly covers my case already.
I’m trying to make up my mind of how to implement this. I am not very happy to have to do this when auth0 already has the solution ready, but at least I’ll try to understand how much work would be involved.
In my scenario I still have a SPA client and an API. If I understand correctly, I can leverage the API to store refresh tokens and provide access tokens to my SPA. I have a lot of gaps to fill to fully understand how this could work.
Here I am already confused:
What I don’t understand is that in case 1, I need to call auth0 for getting an authorization code, while in case 2 I need to go to my backend directly. What can I use to distinguish the cases? Then what credentials can I provide to my backend? In case 1 I have the code, but in case 2 I have nothing.
One possible solution is to use the id token. At step 1, I could return back the id token to my SPA and store it, then use it as a proof to my backend. But id tokens expire too, and that’s not their purpose. It seems I am stuck again, and basically reimplementing what auth0 already does natively.
Also, what about 3rd pary apps trying to use my API? Whey’d need to use auth0 to authenticate users, and they’ll expire too after 3 days / 30 days max.
This is getting too complex for something that should work out of the box. After all, once I am logged in google account, runtastic, etc. I am almost never logged out, or at least expirations may be 1 year.
You’re correct, this would be complex. You would need to stop considering your client application as a SPA, it would be a normal web application that as an implementation detail provides the same UX generally associated with SPA’s that have no server-side smarts and only perform calls into a given API using bearer tokens. Taking a step back, regular web applications can already keep the user signed in indefinitely by leveraging their session and refresh tokens. SPA’s due to the impossibility of using refresh tokens are limited to the current session timeouts being enforced on the IdP (Auth0).
I can research if the hard limit on the session expiration is something we would consider extending, but besides that I don’t have anything else to offer besides solutions that go around the limitations imposed to SPA’s; however, those solutions bring increased flexibility at the cost of complexity.
This would be really useful. I think I have no problems with limitations of SPAs, but allowing me to override the 30/3 days limit would fix my problems and basically provide the same stuff I’d have to reimplement to mimic what auth0 already does. If the current limit is due to security concerns, it could make sense to state it clearly but still allow to do what most other web apps do.
I’ve further investigated the implications of the required changes, I’ll comment below due to space constraints.
@jmangelo without any intent of pressing you and still thanking for the support, may I ask you where/how to keep the question alive until decided and follow its status? It’s becoming more and more important for my company and some devs here are opening up the question of using a service / making things internally (since it’s the only option we have now) and the tradeoffs of costs and flexibility, and this will impact some future decisions. I’d really like to stay with Auth0.
Thanks!
@jmangelo without any intent of pressing you and still thanking for the support, may I ask you where/how to keep the question alive until decided and follow its status? It’s becoming more and more important for my company and some devs here are opening up the question of using a service / making things internally (since it’s the only option we have now) and the tradeoffs of costs and flexibility, and this will impact some future decisions. I’d really like to stay with Auth0.
Thanks!
I have some research and I can say to you that I submitted an issue related to the increase of the maximum limit currently imposed for the SSO cookie. This possibility as not been rejected as we already support the implementation of other measures that would complement the long session (step-up authentication or renewal of a second-factor from time to time. However, I can’t give you any timeline to when this change will be available. I would suggest you to open an idea for this in our ideas section so that other people can also show their interest in this feature.