We’ve successfully implemented an Auth0 login flow using social sign-in exclusively but we’ve noticed an issue with sessions not persisting/keeping the user signed in.
I was scrounging around the docs and followed the session lifetime best practices here Configure Session Lifetime Settings and updated both timers to their maximum thresholds.
In our SDK calls as well during login I have the ‘persist_id_token’, ‘persist_access_token’, and ‘persist_refresh_token’ set to true but still users seem to get signed out after a day or so. I’ve also upped the ID Token Expiration threshold to 30 days as well within the application inside the tenant. I also noticed there are settings to refresh tokens due to inactivity which we presently have disabled. If these settings are disabled do the tokens automatically refresh after a global threshold since the user-set one is not set?
Ideally we’d like to keep our users signed in for as long as possible (I believe the threshold is 30 days for basic accounts) and when they log out destroy the session (which I believe is how the Auth0 session management flow is structured by design).
To clarify we are using Facebook and Google sign in only and don’t have any other sign in flows besides social sign on.
Is there a separate timer for social sign on sessions and how long they persist?
If this is the case, you’ll need to configure your own keys for both Facebook and Google social connections to enable SSO, federated logout, and other features. You can learn more information about the limitations with developer keys here.
Hoped this helps!
Please let me know if you have any further questions. I’d be happy to help.
Thanks for the prompt response! I don’t see the Yellow banner which makes me think that the keys are not development keys. I checked under both Facebook and Google under authentication->social. Is this where we would see the warning?
Another point of interest is our tenant environment tag is still in development mode. Could this cause an issue?
If you do not have a yellow banner, could you please clarify for me whether you have used your own developer keys for the Facebook and Google connections?
You can check by going to the Auth0 Dashboard > Authentication > Social > Facebook/Google.
The environment tag does not have any effect on sessions.
If by “own developer keys” you mean that we are using developer keys on the social provider side (i.e. the integrations on FB/Google’s end) then I have verified that both platforms are in production mode and the client IDs we have in the Auth0 dashboard match those of the production implementations on each of the social integrations. Ergo I don’t believe the keys are developer keys on the social end either.
For completeness, the Facebook connection should have the App ID and App Secret configured, and the Google connection should have the Client ID and Client Secret configured. From your message, I believe you must have configured this already.
If that is the case, then the Single-Sign-On functionality will function properly with your own developer keys. I have tested this myself and can verify that it is working as expected.
You’re right on the money. I just verified both social sign-ons have the respective keys that are needed. What’s more is the sign-in flow works great - it just signs users out in about a day (I don’t have an exact duration but it’s less than a day).
Where else can we check to ensure users stay signed in long term?
Hey @drewHolmes What version of Auth0-PHP is your application building upon? You might simply be hitting the local session lifetime expiration default of the library, which is controlled by cookieExpires during class initialization in the current V8 release.
Just noticed that you’ve mentioned a few particular variables specific to V7, so safe to say you’re not on V8 in that case. V7 uses PHP’s native session handlers to store local session information, which is controlled by settings like session.gc-maxlifetime and session.cookie-lifetime. You might check and ensure those variables in your PHP.INI file are configured adequately for your needs, in case those are the root of your issue.
First off…holy moly… looking at our Composer package it looks like we’re on “~5.0”; we definitely want to get that upgraded as soon as possible. Do you guys have a migration guide to the V8 API? Is there somewhere in the dashboard I can flip the version over or is it managed through Composer?
For a quick fix I’ll take a look at the PHP environment variables you mentioned. Thanks so much for working with me on this one!
Hey @drewHolmes, no trouble! Hopefully we can figure out what’s going on for you and get you sorted out here.
Do you guys have a migration guide to the V8 API?
We offer a migration guide in the GitHub repo covering upgrades from v5 to v7 and v7 to v8.
You might also need to consider what PHP runtime you all are using in your environment;
SDK v7 supports PHP 7.3+, and is now in a bug fix only mode as it prepares for retirement.
SDK v8 supports PHP 7.4+, including PHP 8. v8 is being actively developed and has many new enhancements, so if you’re looking to upgrade, I’d encourage you to move up to v8 to take advantage of that.
Is there somewhere in the dashboard I can flip the version over or is it managed through Composer?
To upgrade your Auth0-PHP SDK dependency, you’d just need to bump the version you’re defining in your composer.json file and follow the migration guide to adapt your project.
I was looking at the migration guide for v8 this morning and it looks a bit involved - but doable! Thanks for all the resources and pointers. Glad to be working with such a fantastic community and team with secure and easy identity management at it’s core!
No trouble at all, @drewHolmes! If you hit any migration roadblocks that I can help with, feel free to ping me here on the Community or drop me an email at evan.sims@auth0.com, and I’ll be happy to help get you through them.
What version of Auth0-PHP is your application building upon? You might simply be hitting the local session lifetime expiration default of the library, which is controlled by