In relation to the second consent screen, you can indeed bypass it. If you’re performing an API Authorization request (aka you included an
audience parameter associated with an API you configured yourself in the dashboard) then ensure that your API is configured to Allow Skipping User Consent.
In addition, the consent screen will also be forcefully shown in some situations if you’re using callback URL’s based on localhost so avoid them if you want to have a similar flow to the deployed application when doing tests.
For the Google situation, this was a decision by Google to always use/show the root domain of the redirect URI being used for the OAuth transaction. When they initially made the change they also talked about the possibility of having a verification process for the client application you configured as an OAuth client in Google which could then allow for that consent screen to show more descriptive information about the application itself. However, I’m not sure where that process stands and if going through the verification process would indeed allow you to achieve what you want. As an additional note, the reason that shows auth0.com is that the callback URL needs to be located in your [tenant].auth0.com account and as far as I’m aware if you’re using the built-in Google integration (social connection) there’s no way around it.