SSO with short, shared inactivity timeout

We are trying to build a SSO solution for a suite of applications (mostly standard web apps, but we would like to support SPA). Per requirements, users must be logged out of all applications after 15 minutes of inactivity, requiring a password to log back in. However, using any one of the applications should keep the user logged in to all of them. A timeout warning dialog must appear prior to the session timing out.

I am seeking high level direction here - I can and have been Googling the low level stuff and have a proof of concept Authorization Code Flow working in our Ruby app, using Universal login and Omniauth as per Auth0’s quick start directions, but I have hit many walls on the session handling end. We have implemented a session timeout warning dialog but now we need to port it to use the shared Auth0 session.

So, some questions to start:
How should the 15 minute timeout work? I’m assuming the tenant itself needs a 15 minute inactivity timeout, in order to share it across the apps. So our apps will need to check in with Auth0 every so often to refresh the session. What’s the best practice for that - set a one minute timeout on our access tokens, forcing a refresh token to be sent every 60 seconds? If so, does that logic exist in OmniAuth (I think not?) or is there a SDK I can leverage, or do we need to roll our own? How can an application discover how much time is left in before the user times out - for example, if the user is actively working in app2, how can app1 determine that it should not log out the user? How do we rate-limit our requests to Auth0 here? Examining shared cookies perhaps? Could app1 poll a cookie and call the backend to indicate it should stay alive? Or should the backend do something with Auth0 when it receives a request, and if so, how does that get rate-limited? Or maybe I’m way off track here, knowing that would help too. :slight_smile:

Again I’m hoping for guidance that sends us in the right direction. I understand this is a complex scenario and will not have a one-size-fits-all answer. Any guidance appreciated.

Mathew Nelson

Hi @mnelson

You are on the right track: set the access token expiration time low, and use a 15 minute inactivity timeout. That gets you 90% of what you need - applications all share the same session and so when the inactivity timeout is exceeded, they will be “be logged out” meaning their access token has expired and they cannot get a new one without entering credentials.

The part I don’t know is the timer, you say you’ve got this. I’ve never seen a timer work elegantly. What happens on applications that are not in use for 30 minutes?

I suppose each app can have a timer they set each time they get an access token.


1 Like

Oh yes, forgot: look carefully at your usage. This is a higher traffic scenario. You may hit rate limits if you have lots of users.


1 Like

Thank you, John.

Regarding the timer: When 13 minutes have passed without activity, we display a countdown timer / click to extend your session. After 15 minutes the user will need to click to redirect to the login page.

What I still need to solve is, if a user is active in a different application, how can I make this timer detect that fact / not appear. Is there a way to check how much time is left on the inactivity timer without affecting it?

Hi @mnelson

I don’t think you can do the timer as you say currently. There is a feature coming for session management that will probably help with this, but I don’t know when it will be available.


The issue we are facing is that users are being logged out of the app and this is causing massive acceptance problems and annoyance and we are quickly losing users because of this. Because there is no session expiration logging in Auth0 and we have ramped up all the timeouts, expiration times, etc. of our tenants to the maximum, I can only deduct that most users get logged out because of the 3 days of inactivity timeout.

Please help me with this issue so that my team can work ahead on the projects.

GarageBand App

Hi @Brawley_896

Did you check the session timeouts in the tenant settings?