I am looking to setup multiple applications that utilize a shared login ecosystem of multiple application under the same domain. I would like all the applications under this domain to have a simple way to authenticate without being coupled with auth0’s libraries/apis.
My idea is having login.matthew.com as the primary application dedicated to authentication, then having app1.matthew.com and app2.matthew.com sharing the same auth0 audience, with different client ids.
To renew their sessions all they would do is redirect to Matthew.com, then login.matthew.com would forward them to auth0’s universal login, and then unwrap all the way back to app1.matthew.com with the auth token.
Is this a valid and best way to do this? Its seems a little clumsy with multiple redirects, but maybe that’s okay. Is there another way to renewsession maybe via an API, that the backend of login.matthew.com can renew instead of redirects?
So you basically want SSO / Single Sign On across multiple applications? Have you looked at this blog post:
What you’re describing sounds exactly what’s basically the core idea of Auth0.
I am looking to setup multiple applications that utilize a shared login ecosystem
Yes, the shared login ecosystem would be Auth0 in this scenario. You can configure a custom domain, such as login.matthew.com to point to Auth0 as the central authorization server.
without being coupled with auth0’s libraries/apis
You don’t have to use Auth0’s libraries as it’s all standard OAuth2 flows. You can therefore use any other (non-Auth0) OAuth2 library that works fine for you.
I think i should’ve elaborated a little further, I apologize. I want to have login.matthew.com be a hosted website, that has 3 different options for how the user can login.
For example they can login with:
Email/Password
Passwordless Email
Passwordless Text
These options are basically just links to the authorize endpoint with various configurations to provide those solutions.
Does that make sense? If not, do you have a suggestion? I want the user to feel like they are landing at matthew.com, but then a lock renders once they select their login option.
Use a custom domain login.matthew.com that points to the Auth0 hosted login page, but you customize the login page there in a way that you described, incl. the selection and the showing the Lock by using the Lock library (but within the Auth0 hosted login page), and a bit more of Javascript .
The other way is to embed the login on a page hosted by yourself, on login.matthew.com, meaning that you use the Lock library on your server, and in the end, just call the Auth0 APIs (-> so here, you would definitely need to use the Auth0 APIs).
Downside of embedded login is as stated on the Lock docs page:
Embedded login for web uses Cross Origin Authentication. In some browsers this can be unreliable if you do not set up a Custom Domainand host your app on the same domain . Using Custom Domains with Auth0 is a paid feature. If you cannot use Custom Domains, consider migrating to Universal Login.
