The hosted login page works great, but on webAuth.authorize() it navigates away from the page to show the login screen with a gray background.
Is it possible to open it as an modal overlay (e.g. in an iFrame)?
Also, with closable: true if the hosted login modal is closed it does not re-direct back, but simply closes the modal and stays on the page with a gray background. How can I trigger a redirect back to the callback page?
The navigation is intended and tightly associated with the authentication/authorization protocols used underneath (OIDC/OAuth2). A good example of this the navigation to accounts.google.com when performing sign in to Google properties. At this time this navigation has the side-effect that it is performed to the domain associated with your Auth0 tenant which in some situations may not be the experience you aim for. We are aware of this situation and plan to address in a way that it would be possible for the hosted login page to be accessed from a domain more recognizable to your end-users. However, there’s no definitive dates on when/how this will be available.
In conclusion, I would not recommend attempting to do that from an iframe; if you really must not disclose the presence of the Auth0 tenant domain then you may want to consider embedded authentication where Lock is shown on the client application domain itself, however, this has its drawbacks and will also have more implementation overhead.
In relation to cancelling the flow from the page itself, I’ll need to check what (if any) options are available and then get back to you. In general, the end-user would just use the browser back button to navigate back to the client application, but that may not provide the same exact experience you were looking for. If you can update your question with more context on why you need to have such ability on the page itself instead of just not allowing Lock to close and then rely on browser back button that would be great.
Thank you for taking the time to give such a complete answer.
The login is an optional feature intended to reward the user with additional and personalised functionality in return for registering. Thus the login is not a gateway, but a feature on the page to unlock additional content.
A user might be in the middle of reading content when they need to login/register to interact with user specific content. It would be OK, if not ideal, for the page to reload, but closing the login would have to return the user to the same page and we would very much prefer for the login to be overlayed on the page. So this is not so much about revealing the Auth0 domain as it is about providing a seamless user experience.
Thank you for the embedded authentication link. I suspect this is the route we will have to go.
Because our website is fairly large and uses webpack one issue we came across when we installed the auth0-js package with npm our newer web-pack v3.0 did not work with your pre-built version which seems to use web-pack 1.0. The global object injected by web-pack did not get injected, so we had to import from the source so our newer web-pack version could bundle it, like so:
import WebAuth from "../../../grunt/v2/node_modules/auth0-js/src/web-auth/index"
Also, when I tested installing using npm auth0-lock the auth0-lock node-module did not appear to be built and I think this is the module I would need for building an embedded lock.