Given that you’re using the hosted login page the fact that you plan to switch from username/password to passwordless is mostly irrelevant as the end result is that a session is established at the identity provider (your Auth0 tenant/domain) and tokens are issued to the client application.
For a browser-based application the issued tokens should be relatively short in lifetime given the browser environment is a very hostile one and the chances of tokens leaking are greater. However, your browser-based application can leverage the session that was established in the identity provider to obtain new tokens without forcing the user to actively authenticate again (see the
checkSession method in Auth0.js library).
Using that approach you will be able to obtain new tokens until that session exists; at this time this means it will last until the maximum lifetime configured for the session is reached (defaults to seven days, but you can configure it through SSO Cookie Timeout field in your tenant advanced settings) or the user is inactive for three days (the inactivity timeout is currently not configurable) or the user terminates the session (would happen if the logout in your application also triggers logout in Auth0).
In conclusion, with
checkSession and SSO Cookie Timeout you may have some additional flexibility that gets you closer to your requirements, but the non-configurable inactivity timeout may still be an issue. I can let you know that there are plans to give you more control and flexibility over the session in question which would likely meet all your requirements, but at this time there is not yet definitive information about this.