Auth0 Home Blog Docs

Auth0js v8 or v9 on a custom Hosted/Universal page?

hosted-login
auth0js
hosted-login-page

#1

- What are you trying to achieve? What is the use case or idea behind it?
I am trying to establish whether it is currently best practice to use auth0js v8 or v9 on the ‘universal’, née ‘hosted’ login page.

Up until recently, the documentation very clearly stated that auth0js v9 was for use within client applications (an Angular SPA in our case), using the .authorize() method to send us to the ‘hosted’ (now ‘universal’) page, where we should use the v8 library within the custom page itself to call .redirect.loginWithCredentials() to perform authentication.

A touch unorthodox to use one version of the same library in one place and an older version in another, I mused to myself, but hey ho, the instructions are fairly clear and it worked!

The docs have now changed, and I cannot find any reference to any warnings or instructions not to use v9 on the 'universal, née ‘hosted’ page. Indeed, the auth0js v9 docs say quite explicitly “using webauth.redirect.loginWithCredentials is the correct choice for use in the universal login page, and is the only way to have SSO cookies set for your users who login using universal login.” This seems to me to be a pretty clear indication that one might use the method .redirect.loginWithCredentials() on the auth0js v9* WebAuth object within one’s ‘universal’, née ‘hosted’ login page to authenticate users.

Sadly this doesn’t appear to work. In current v9*, the .redirect.loginWithCredentials method appears to call through cross origin auth code, and when we switched our custom ‘universal’ (née ‘hosted’) page from using v8 to v9 within our development tenant, the login function would not work, with no error or any clear indication of what might be going wrong.

Being the enterprising, sprightly young go-getter of a developer that I surely am, I thanked the open-source gods and dived enthusiastically and not-at-all-begrudgingly into the auth0js github repo, while debugging my broken custom ‘universal’ (née ‘hosted’) page.

It appears that the WebAuth object now contains a _universalLogin property, produced in the hosted-pages.js file. This object contains a login method (documented as loginWithCredentials, with broken links to the source file), and that method does indeed appear to allow a user to login on the ‘universal’ (née ‘hosted’) page with auth0js v9.

So my main question is should we be using auth0js v9 and the call webAuth._universalLogin.login or should we be using v8 and webauth.redirect.loginWithCredentials? Does the underscore in front of the _univeralLogin property indicate that this is some internal implementation that we shouldn’t be using directly in our client or custom ‘universal’ (née ‘hosted’) page code? Or is there some detail of the v9 library that I’m missing, which allows us to use a loginWithCredentials method somewhere on the v9 library object on the ‘universal’ (née ‘hosted’) page?

I can find migration guide material regarding updating clients through various versions of the js library, but I cannot currently find any clear and (to my understanding) simultaneously correct information about what version of the library and which methods we are currently advised to use a custom ‘universal’ (née ‘hosted’) page. I would be greatly reassured if someone could point me towards such information and demonstrate that the inability to find it is a failing purely on my part!

*v9.,3.3, the latest version at the time of writing.


#2

Not sure if you’re still having issues, but, for future reference: all you have to use now is webAuth.login. It will automatically decide if you’re running from the Universal Login Page or not and act accordingly.