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:
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.
@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:
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.
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?
User loads app
1a. Check with auth0 to see if user is logged in, if they are nothing to be done
User not logged in, redirect to auth0 hosted login page with code grant type, supply api url as redirect_uri
Redirect to backend api after auth
Backend api uses code to get access, id, and refresh tokens from auth0 /token endpoint
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?
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.
Thanks for the kind words, however I must interject here.
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.
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.
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
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.
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!
