Hi there
I am trying to integrate with auth0 using the embedded login approach (aware that UL is recommended). I was going to start using Auth0.js SDK. but then I came across auth0-spa-js SDK and wonder if that can be used with the embedded login. From the APIs this SDK provides, I didn’t see anything that could be helpful. Please guide here.
thanks
No, that SDK (auth0-spa-js) is aimed specifically at universal login scenarios so the option available would indeed be to use the Auth0.js SDK instead. Although as you said, ideally, the universal login approach should be used and not embedded login.
Just a note that embedded login for web applications will be significantly constrained if you don’t use a custom domain aligned with the web application domain and in addition an Auth0 tenant only supports a single custom domain.
Hey @jmangelo thanks for the clarification.
By this “custom domain aligned with the web application domain”, do you mean?
My login page: login.company.com
Auth0 Tenant: auth.company.com
Yes, the requirement would be for the domains sharing a common parent domain that is not an eTLD. In your example the common parent domain would be company.com which would satisfy this requirement.
@jmangelo is there a workaround this? To make authentication possible between 2 systems having different top level domain names.
I’m afraid the constraints are imposed by browsers being more conscious about the use of cookies in flows involving truly independent domains. In this case these domains are independent, but both under your control, however, since the browser does not know this it assumes the worst scenario which could be domains trying to track user activity.
In summary, since cross-origin authentication flow depends on cookies being set in a way very similar to what tracking cookies would also use I don’t believe there’s any workaround.
The available alternative would be to use universal login flows where the application redirects to the identity provider domain. This could be done in different ways and technically if authentication is a sporadic event it could even use a popup in order to avoid the client application to reload.
What are the requirements that forced you to only look at embedded login?
@jmangelo There was some requirement from the client to have application serve the login page rather than Auth0. Now, we have convinced client to use the Universal login page.
thanks
We also have requirements for a very specific login UI.
In the industry it is important, I would guess that if you would allow heavy custom code to really personalize the UL it would be the perfect solution.
Hi @basickarl,
Thanks for the feedback, and welcome to the Community!
You can fully customize classic UL with your own UI. Check out this doc.
The discussion here is about an embedded login solution. I’m going to close this thread, feel free to start a new topic with any questions you might have.