If your requirements do not allow for the redirect to the Auth0 hosted login page (which supports customization) then for now you’ll need to keep using Auth0.js v7.
Moving to Auth0.js v8 at the moment and, as you mentioned, implies that the SSO session will need to be established by redirecting to the hosted login page so that you can then later use the approach described in the silent authentication tutorial in order to renew user tokens.
We already discussed and considered improving the possibilities available to people implement highly custom user interfaces that need to be embedded in the client application itself and that at the same time want to move to recent versions of the available libraries. However, at this time this is not yet available so for that very specific scenario you should continue to rely on Auth0.js v7, which is still supported as stated in the associated GitHub repository:
We recommend using auth0.js v8 if you need to use API Auth features. For auth0.js v7 code please check the v7 branch, this version will be supported and maintained alongside v8.
Update:
Q3]
I can relate to your point about the possibility of having only a subset of the library for the use case related to the customization of the hosted login page, but would it really bring anything of value? I suspect it would be more overhead for little benefit. For example, assuming CDN is in use being the exact same script means a possible cache reuse between hosted login page and the client applications themselves. In conclusion, I’m not sure this will change.
Q4]
In general, if you go through the hosted login page then you can leverage more stuff from the service you’re using instead of having to do it yourself in all your client applications custom login pages. For example, the hosted login page can provide built-in protection against cross-site request forgery for the login; depending on your situation and specific client applications this may not even be an issue, but the important take is that going through the hosted login page would get you something for free and one less thing to worry about. However, as it’s almost ever the case, reusing something instead of building it yourself will impose certain restrictions.
At this moment, as @amaan.cheval mentioned, the recommended approach to make use of renewAuth is to have gone through the hosted login page so that a session can be established and the tokens can be renewed based on the session. This can be used through Auth0.js v8; if you can’t make use of the hosted login page then as already mentioned there is not yet an upgrade path and you will have to continue to use Auth0.js v7.
Q5]
This is mostly my opinion, but in general the user should input their credentials only within the domain/system that owns it. If you have App X that allows to login with Google, the user expects to be switched to Google if he has to input their credentials.
The case for an identity provider as a service, like Auth0, is slightly more complex; in truth the credentials are being managed by Auth0 so inputting the credentials at the hosted login page would make complete sense. However, the end-user may not have that perception, depending on how you implemented it. If you implemented sign-up and login through the hosted login page then the user would have this perception and this would be a non-issue, however, if you have a registration process specific to your client application then the user may indeed notice this disconnection between where he registered it and where he logins.
Again, as already mentioned, we’re working on improving the available options for this last scenario in the latest versions of our libraries.