We are currently using version 7.x.x of the auth0js client library and it works great for us in our SPA. We do not rely on auth0lock, we have a need for strongly tailored UI components. So, in our app (client), we create an instance of the Auth0 class (passing in domain & clientId) For login we call the .login(...username, password...)
function which relies on /auth/ro
(RS256) and store the returned id_token in local storage.
Our middleware adds the bearer token on secured requests to our API & we verify the signature with the shared secret. For token renewal we call .renewIdToken(aboutToExpireTokenFromLocalStorage)
which relies on /delegation
.
Upgrading to the newest version of auth0js (v8) seems to imply an ‘upgrade’ to HS256 & the usage of the /auth/token
endpoint instead. Our assumption was that we simply needed to change our token verification step & instead use the public key to validate the signature (imposing the correct algorithm, HS256, on our JWT library). This worked. We’re not clear at all on token renewal since it no longer works after the upgrade.
As you can see we made some assumptions, with our current implementation being our starting point, it also wouldn’t be easy to completely shift this upside down as you can imagine. So, after going through the current documentation it still isn’t fully clear to us: Generic vanilla JS documentation explains session handling but it doesn’t explain keeping the session alive (I know sessions do not exist, but token renewal isn’t mentioned in the guide): https://auth0.com/docs/quickstart/spa/vanillajs/03-session-handling
The only reference we found for usage in a SPA was on the silent authentication docs: Configure Silent Authentication
In the case of single-page applications, the renewAuth method from auth0.js can be used to perform silent authentication within a hidden iframe, which results in no UX disruption at all.
However this implies having an SSO session and the documentation implies the following:
For this request to succeed, the user must have an active SSO session at Auth0 by having logged in through the hosted login page of your Auth0 domain.
Which we clearly aren’t looking for given our desire to have a custom login for a seamless experience and UI.
Update 1. - Additional Questions (as follow-up to answer by @jmangelo)
Q1)
Would you have an ETA for when an upgrade path is available?
We planned on implementing a custom OTP implementation using the redirect capabilities Auth0 offers via rules: Redirect Users from Within Rules. However, this clearly states that it isn’t compatible with the Resource Owner endpoint (/oauth/ro).
If you have any suggestions on how to move forward or what the strategy is of Auth0 moving forward. Do let us know. Not being able to add OTP is important to us.
Small side question; how would Auth0-lock handle this? I can see from github that it’s using auth0-js v8, so I can only assume that it’s now also calling /oauth/token. How are consumers of this library expected to keep the user authenticated without having to re-enter username/password.
Q2)
Above I quoted from the documentation the following:
For this request to succeed, the user must have an active SSO session at Auth0 by having logged in through the hosted login page of your Auth0 domain.
Is this fully correct? As far as I know a user can log in via a custom form using auth0-js. When the flag SSO=true
is there it would still create an SSO session (via the redirect). Would this still be a valid SSO session in scope of the renewAuth
functionality in v8?
Update 2. - Additional Questions (as follow-up to answer by @amaan.cheval)
I’m not sure I see the benefits as an integrator of the Auth0 framework, on the contrary. This documentation Auth0 Universal Login shows a custom login page using auth0-js v7 (which should get upgraded to v8 asap). Q3] Isn’t it a bit odd for it to be using the same library as the one that is used on client applications? Shouldn’t this be a subset for usage on the login page? Another factor that supports the library confusion is seeing the non modified login page use this endpoint: /usernamepassword/login (as opposed to /oauth/ro or /oauth/token`).
That being said, I guess we could build and package a custom login app which embeds auth0-js, package/deploy it somewhere and and have it referred from the ‘custom login page’ template (assuming we can) and then bootstrap it with relevant information coming from @@config@@, not ideal from a deployment perspective but doable. But we may well deploy & serve this ourselves, have it deployed under the same domain & make deployment easier.
Q4] So what benefit are we getting from going via the ‘hosted login page’?
The only difference I see is the domain being specific to the authentication step: In regards of user experience we don’t like this since the tenant_id+auth0_domain (we use technical tenant ids) being in the url during the login flow is something we don’t like to expose to the end user. It’s likely to be confusing to them: Q5] Why would they want to provide credentials to a URL that is not related to the initial URL they requested? (we are using an on premise appliance so at least we can get the domain to be the same but for SaaS that argument is mute).
It’s a different story if the auth0 server is just used as an agent in a series of redirects to an IDP, since an end user won’t even notice going via an Auth0 URL.
As a developer, who is very concerned but not fully knowledgeable on security (it’s one of the reasons we rely on Auth0) could you give me some ammunition to use for when we need to argument usage of the hosted login page that goes a bit beyond “It’s more secure”.