So the access_type=offline parameter typically relates to the situation where you require an Auth0 Refresh Token. For clarification, Auth0 tokens - i.e. ID Token, Access Token and Refresh Token - are independent artefacts and are separate from those generated by Google or any other OIDC/OAuth 2 compliant upstream IdP .
When you use “Continue with Google” in Universal Login, Auth0 is leveraging the Google Authorization Server as an upstream IdP. The same is true if you use the likes of Facebook, Twitter or any other 3rd party supported by Auth0: the Authorization Server provided by those services are used as the upstream IdP. For convenience, Auth0 typically stores the Access Token that might returned by an upstream IdP; such a token is stored as part of the user’s profile record in the corresponding entry in the identities array (as mentioned in previous comments). Such tokens are typically short-lived, and typically are provided so that Auth0 Extensibility - such as an Action, Rule or Hook - can call upstream IdP services to obtain additional information about a user. Auth0 does not typically store any Refresh Token delivered by an upstream IdP.
If your application is looking for a Google specific Access Token (or Google specific Refresh Token) in order to call Google specific APIs - either directly, or via one of the many Google SDKs (such googleapis) - then you will typically need to redirect to the Google Authorization server directly in order to obtain said token. You can do this once authentication via Auth0 has completed, and it should be a seamless operation - i.e. the user should not be asked to interactively login - as the (Google) SSO session already established by authenticating via Auth0 will be used. You can find more on Google Authorization here.
Hope this helps 