There’s a few things in play here; some will depend on configuration while others will depend on identity provider policies that you may not be able to influence.
Technically, if you force the user to prove again that they are who they say they are then it’s not exactly a single sign on experience. From an Auth0 IdP perspective you have some control over how this happens as you should be able to instruct a specific client application to not reuse any previous authenticated session that already exists at Auth0 IdP.
In the scenario that the final IdP is Google the above would mean your client application asks Auth0 to prove the user identity, Auth0 does not use any previous session so it must ask Google again to prove the user identity. However, at this point is now Google that decides how it proves the user identity. It could prove it by having the user login again or by simply reusing a previous authenticated session . Google chooses to use a previous authenticated session.
Although, the authentication to Google is following the OpenID Connect specification and that specification includes a prompt=login parameter that instructs the IdP that the user should login again; Google does not support the login option for the prompt parameter. See Google docs on the prompt parameter.
In conclusion, if it involves an external IdP then it’s at the discretion of said IdP to choose to use an authenticated session and not force the user to input credentials again when a client application requests proof of a user identity.
Having said that you can use Google authentication through Auth0 as a first-factor and then always force the user to complete a second-factor after Google has provided you with the identity of the user. However, as said before, always forcing this seems to go against the objective of SSO.