For convenience, Auth0 typically stores any Access Token that might returned by an upstream IdP as part of first-factor authentication. And Auth0 typically stores such a token as part of the user’s profile record in the corresponding entry in the identities array; accessible via a call to the Auth0 Management API (as discussed). However, 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 - i.e. 3rd party APIs - to obtain additional information about a user as part of the login process. Auth0 does not typically store any Refresh Token that may be delivered by an upstream IdP, nor does it automatically refresh any stored Access Token delivered by the upstream IdP “behind the scenes” as it were.
For anyone looking to obtain a specific Access Token in order to call some 3rd party API from their application (e.g. a Google API, OneDrive API, Facebook Graph API, etc) - either directly, or via an SDK - then the recommendation would typically be to perform some redirect in the application to the 3rd party Authorization server directly. This 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 (3rd party) SSO session already established by authenticating via Auth0 will typically be used.
Building a solution that relies solely on using the 3rd party tokens Auth0 keeps will likely be problematic, as when the token expires there is no option but to go back to the 3rd party Authorization Server because Auth0 has no way of renewing any existing - or even obtaining a new instances of - the token for calling the 3rd party APIs.
Hope that makes sense 