SPA keep me logged in for 6+ months

[dillon-courts]

Hi,

I am evaluating Auth0 as an identity provider for an authentication/authorization overhaul I am working on for a client. One of the requirements is that a user must be able to stay logged in for 6+ months. Really the time is arbitrary but 6 months it the minimum. I was reading this post for information:

renewAuth (silent auth) session expiration

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!

however, I see that it has been closed and there was never any resolution. Can anyone tell me if the information in that post is still relevant and whether or not the functionality to adjust expiration times has been implemented?

The architecture is a multiple Single Page Application (SPA) website that functions as a single website with subdomains. Users should stay logged when moving between SPAs on different subdomains. The SPAs are supported via an API layer that we have complete control over.

Thanks!

[kimcodes]

@dillon-courts there are a few steps we can take, but TLDR I do not believe we can guarantee a user will be logged in for 6+ months at this time. We can set the SSO Timeout in our tenant settings, this determines how long you can still get a new token without having to log in, which is set to 7 days by default, but we can set to a max of 30 days. This is possible so long as the user uses the session within 3 days. There is an inactive timeout that will require them to enter credentials again after 3 days of inactivity (currently non-configurable). We can take advantage of the checkSession call to refresh our tokens. See here:

Auth0.js v9 Reference

We are looking at providing more configuration options and flexibility. However, I wouldn’t have any further details or timeline to give at this time.

[dillon-courts]

Thanks for the response @kimcodes . That gives me a solid understanding of what is possible out of the box with Auth0. It seems I’ll need to get creative to satisfy the stay logged in requirement. Can I run a high level approach by you?

1. User loads app
   1a. Check with auth0 to see if user is logged in, if they are nothing to be done
2. User not logged in, redirect to auth0 hosted login page with code grant type, supply api url as redirect_uri
3. Redirect to backend api after auth
4. Backend api uses code to get access, id, and refresh tokens from auth0 /token endpoint
5. Backend redirects to SPA and passes access and id tokens

After this login flow has happened once we will store the id_token in a cookie. The id_token can be sent to our API server during step 2 instead of redirecting to the auth0 hosted login page. The API can use the id_token to identify the user, lookup the refresh token, and renew the users tokens.

I realize this has some security implications, but is the best approach I can think of at the moment to allow for more durable ‘sessions’. Does this flow seem feasible? Or do you have any other suggestions?

[wshayes]

Before you do all of that, I’d just build an authentication service so you can set it up the way you want. Auth0 is great as it provides a robust, highly validated service to do this if you can work with their options, but the gist of what it provides is a service to take a login/pw/token and provide a token.

I would build my own auth service for your situation especially since security isn’t that important.

[kimcodes]

@dillon-courts I am going to have to check the use case with my team. I will respond once I have more information if this would be possible.

[jerdog]

Thanks for the kind words, however I must interject here.

@wshayes

I would build my own auth service for your situation especially since security isn’t that important.

This should never be the reason to roll your own authentication service… Unless you have the security experience along with the software engineering experience to stay on top of the often daily changes and risks on the internet and in software, you’re taking a huge risk for your client (and yourself) by rolling your own. Security should always be important, especially when you’re dealing with other people’s data, given that hackers will use easily exploitable services to access other, more difficult ones.

[wshayes]

When Dillon said that convenience trumps security and they don’t really care about security as long as they can stay logged in for half a year or more at a time - it kind of obviates your issue with security. Any system with a requirement to be logged in for months at a time pretty much isn’t secure (and not supported obviously by Auth0).

Yes - there are a lot of mistakes that can be made building your own authentication system, but you can build a system that is secure especially if it doesn’t have to try to be all things to all people.

All that said, I’m happily using Auth0 because it’s secure, been vetted by numerous users and is on top of robust infrastructure. Started using Keycloak and realized how much engineering was involved in making it robust and fail-over safe and happily switched to Auth0. Complexity of using Auth0 though is quite high - still not really sure how to set things up correctly.

[jerdog]

Certainly. Feel free to shoot me a DM to discuss ways to reduce the complexity for you (and potentially others), and we can stop cluttering what @dillon-courts is attempting to do

[bragma]

A lot of web sites offer a “keep me logged in” still I don’t think they don’t care about security. The problem is that even a simple login can be difficult for some users and sometimes you have to try to do things as much securely as possible while retaining the customer. If customers flee, you don’t have anything to secure.

We’ll see what WebAuthn will bring…

[konrad.sopala]

Hey there!

Sorry for such delay in response! We’re doing our best in providing the best developer support experience out there, but sometimes the number of incoming questions is just too big for our bandwidth. Sorry for such inconvenience!

Do you still require further assistance from us?