Auth0 Home Blog Docs

Signing in without leaving my single page application

lock-10
single-page-applicat

#1

I’m using Auth0 lock on my single page application. I’m annoyed by the fact that it leaves the actual page, to do the redirection. Is there a way to tell it to not leave the page? I’ve seen authorization mechanisms that open a new tab, send a message to the original tab, and close the new tab.

The problem I’m having is when the user enters data in the app prior to being authenticated, and then wants to authenticate to save that data in his account. By leaving the page, I’m losing all unsaved user data. I could make a shady local storage backup of what’s being inserted, but I wouldn’t know when to delete it.

That seems like a fairly common scenario…


#2

The redirection mechanism is pretty tied to the underlying protocols at work (OpenID Connect/OAuth2) so having to have it is almost a given. Given these protocols are also in widespread use, end-users themselves are also pretty accustomed to this flow (for example, sign in to a Google property will redirect to the login page accounts.google.com).

You’re correct that this redirection should not impose negative side-effects on the overall UX, like it would be the case, if it indeed interrupted the flow the end-user was performing before authentication was required. However, this should be something that the client application is responsible for with a bit of collaboration from the authentication protocols. In the case of the OpendID Connect/OAuth2 there’s support for a state parameter that among other things can be used by the client application as means to know where to put the end-user after the authentication completes and in this way make it easy for them to continue what they were doing.

IThis will generally depend on Web Storage API’s for the SPA scenario and I have to admit that I don’t personally see it as shady. The Web Storage API provides both localStorage (associated with an origin) and sessionStorage (associated with the origin but also tied to the browsing context).

If you consider your suggested flow of doing authentication elsewhere then any data entered by the user in a form would be available/stored until the end-user closes that tab or submits the form after completing authentication. If you go with the redirect and put that form data into sessionStorage then that same data would be available/stored until the end-user closes that tab (browsing context) or completes the authentication and you remove it. In both cases the data would have very similar lifetimes and you would know when to delete it explicitly in the second case.

Having said that, Auth0 Lock supports a popup mode that would be more similar to what you describe, however, the current recommendation is to use an OIDC conformant client and cross-origin authentication in the scenarios where you want to embed Lock in the client application itself and in this case the popup mode is not supported per the information available in the README of the associated GH repo.


#3