Avoid session expiration

[MrRennen]

• auth0-lock: 11.22.4

Hi,

I would like to avoid having the users sign-in frequently. Our system is consumer facing and doesn’t store sensitive data, and so we would like the users sign in as least as possible, preferably once a year or at least 6 months.

Currently, we are using auth0-lock in our React frontend and it seems to be expiring every day. I believe this is due to the setting: “Token Expiration For Browser Flows (Seconds)”, which is set to 24, which is the max value - correct?

I thought of using the refresh token to refresh the access token on startup time, and thus avoid having the user to re-login. Is that a right approach?

However, I noticed that we don’t even get the refresh_token in the response. I have enabled “Offline Access” but that didn’t help either. Is this not supported when using Lock?

Anyways, from the documentation, it seems that Lock should be using checkSession to renew the token, and so we implemented that using a scheduler. However, that is valid only when the user is actively using the system - the access token will still expire after 24 hours.

How do I achieve this? What should I do?
Is there a place to get a fully documented example that I could just use in our react app, preferably without re-writing all the lock related code?

I understand that I may need to refresh the token periodically in the backend and load it in the frontend. But (1) I don’t even manage to get the refresh token. And (2) Not clear how the frontend authenticates with the backend if the access token expires.

[john.gateley]

Hi @MrRennen

You need to set your session timeouts. They are in your tenant settings.

Click on your tenant name in the dashboard (upper right) and choose settings, then the Advanced tab.
Then adjust your “Log In Session Management” times

John

[MrRennen]

Thank you John for the quick response.

Two questions:

1. From this screen, I can see that the max inactivity timeout is set to 3 days and the max timeout is 30 days. How can I extend it further?
   

   

2. From the screenshot above, you can see that my account is already set to the max value, yet still requires a login.

I don’t understand why preciously, but I suspect that it requires it, because the auth0-lock package that i used is based on the “token expiration for browser flows”, which its value cannot be set to more than 1 day, see screenshot.

Can you confirm that this is the cause of the frequent reconnects?
If so, back to my original question - how to achieve this?

[john.gateley]

Hi @MrRennen

Long lived sessions are an enterprise feature. With the upgrade, you can have sessions up to 100 days inactivity timeout and 1 year absolute timeout.

For the 1 day issue, I would need to know what is triggering the re-log-in. Are you using a redirect flow (auth code + PKCE most likely) to log in?

If you are using ROPG, then you’ll need to use a different approach (the refresh token approach), as the Auth0 session is not created with ROPG.

But ROPG is NOT recommended (and not just by Auth0, but by the industry in general).

Which one are you using (ROPG or a redirect flow)?

John

[MrRennen]

Thank you for your reply.
To be honest, I’m not 100% sure.

We use the library called auth0-lock. It seems to be making the following calls:

(1) POST https://myamy.auth0.com/co/authenticate, with this body:

{
 "client_id":"lR7ybd7au4xBLT6rGR5xBKE5WnmKDM26",
"username":"<email>@gmail.com",
"password":"<>",
"realm":"Username-Password-Authentication",
"credential_type":"http://auth0.com/oauth/grant-type/password-realm"
}

And that is the response:

{
 "login_ticket":"S-5RscK_vVVqs7Hr2RbfNdjvZIuyU51I",
"co_verifier":"ziWk8TQO19gdkXKF0nBe3eXaJoCimYw9",
"co_id":"jOQqM2nVzFaD"}

(2) GET https://myamy.auth0.com/authorize?

https://<domain>.auth0.com/authorize?client_id=...&response_type=token&redirect_uri=...&scope=openid%20profile%20email&audience=https%3A%2F%2Fapi.demo.audience.io%2F&state=...&realm=Username-Password-Authentication&login_ticket=...&response_mode=web_message&prompt=none&auth0Client=...

I don’t see any response in my browser’s devtools.
But from debug prints, I suspect that it returns a result with the following format:

{
"accessToken": "ey.....",
"appState": "aX5Dcf8n5fXay_N5Ntj7f8qjyuFNUZzy",
"expiresIn": 86400,
"idToken": null,
"idTokenPayload": null
"refreshToken": null
"scope": "openid profile email"
"state": "aX5Dcf8n5fXay_N5Ntj7f8qjyuFNUZzy"
"tokenType": "Bearer"
}

(3) At this point, I’m making a call to GET https://.auth0.com/userinfo
using the access token received at the previous step.

Is this ROPG or a redirect flow?

[john.gateley]

Hi @MrRennen

This is ROPG (see /co/authenticate). So your timing is determined by the times on the access token. You can change the timing there (go to the API referred to by audience https%3A%2F%2Fapi.demo.audience.io and change the access token timeout)

I don’t recommend this though, the access token cannot be revoked, so making it long lived is a risk.

A redirect flow and sessions is a more secure approach.

John

[MrRennen]

Thank you for your response.

There are 2 values there → Token expiration and Token expiration for browser flows.
It seems to be using the 2nd value, which cannot be extended over 24hours.

If I switch to redirect, will I be able to use the first one? Or I’m locked to the 24 hours for as long as I’m using the auth lock sdk?

Also - seems like the “Universal Login” is using the redirect method, however it’s still bound to auth lock package, as it’s referencing it in a tag the html source.

I presume the correct thing would be to use a rotating refresh token, however auth lock package does not seem to support it. Can you confirm?

[john.gateley]

Hi @MrRennen

The lock.js package is just a widget SDK, it does a lot of things, depending on the parameters you pass.

There is a lower level SDK, Auth0.js, that you can use if you want even more customization than lock provides.

And you can always invoke the Authentication API directly for the most control.

If you switch to a redirect flow your session timeouts are different. They are under the tenant settings.

Or you can use rotating refresh tokens. The choice depends on SSO requirements.

John

[MrRennen]

Thank you @john.gateley
Now I understand it better.

Nevertheless, the expiration settings under the tenant settings are allowing max 3 days of inactivity and max 30 days (regardless of whether being active), which is insufficient for me either.

I really don’t understand those limitations. Why one scenario is greater than the other, and why not let your customers greater control over those time limits.

[markd]

I imagine it is an issue of resourcing (and maybe strategic Sales decisioning too!) Depending on your account level, you can get 100 day idle timeout and 365 day forced logout, but you need to upgrade your account (might be Enterprise level accounts only). Auth0 has to maintain that session state data on their end. Resources cost time and money.

[MrRennen]

Why do I need to pay more money just to prevent from being forced to be logged out?

Oh, and by the way - you’re wrong. What you’re saying, like other auth0 experts in this forum - simply is misleading and incorrect:

Because I followed your tutorial - I’m now stuck with the lock.js that limits to 3 days. This is the limitation of this product. Nobody tells you that up front, you have to find out after several days of trial and error and digging in the forums. And so - unless I waste expensive developers time to rip off my current implementation and replace that, I’m stuck with the 3 days - even if I’m paying you more. So not only that you got me stuck, now you suggest upgrading even though it’s not gonna help. Thanks a lot (not!)

[markd]

Hello @MrRennen,

The SSO session limitations are pretty clearly documented at the link below. As for why the limits are what they are, as a Community volunteer I’m not in a position to answer that, other than to reiterate my previous point that maintaining session state costs resources that need to be paid for. If you would like to see the session limits changed I would suggest submitting feedback here.

https://auth0.com/docs/get-started/dashboard/configure-session-lifetime-settings

[lpcarignan]

I’ve checked the link ‘Configure Session Lifetime Settings’ as I’m running in the same issue as explained at the beginning of this post.

My users have to login back in every 4hrs. I’m guessing it’s because I’m running on the free plan so even if I put another value (Ex: 20400 minutes), it won’t be taken into account. I’m also using Auth0 Lock.

The page I mentioned above has the following description for Require log in after parameter:

Timeframe (in minutes) after which a user will be required to log in again, regardless of their activity. Will be superseded by system limits if over 43,200 minutes (30 days) for Developer or Developer Pro or 525,600 minutes (365 days) for enterprise plans.

When I look at Auth0 current plans, it doesn’t mention ‘Developer’ or ‘Developer Pro’.

So my ask to this community is: If I take the B2C Essential plan, will a change to this value be taken into account? Or am I stuck at 4hrs because I use Auth0 Lock library?

Thank you for your time,

Louis-Philippe