If your client application is an Angular SPA then you need to treat it as that and the way the client application resources are served is mostly irrelevant, more specifically, the fact the HTML, JS, etc is served by ASP .NET Core based server should not have a bearing in the client application authentication.
If you followed the Angular quickstart for custom login through Google and Facebook then the tokens you’re obtaining are already being issued by Auth0 after the end-user authenticated with the social provider. In this situation you should not be using the /oauth/access_token endpoint; that’s for very specific situation where an application went directly to the social provider and not though Auth0.
In conclusion, you should not be calling that endpoint and instead use the issued tokens that you received. The ID Token will contain information about the user who completed authentication, while the access token depending on your configuration and of the features you’re using will either allow you to call the user information endpoint at Auth0, call an API you configured in your Dashboard or both.
For reference information about the scenarios where the access token allows you to call an API you configured, see: Authentication and Authorization Flows
If your mention of ASP .NET Core was due to the fact that you also have an API that exposes services to your client applications (including the Angular one) then you should definitely check the above documentation.
Calling the /userinfo requires using an access token; this access token can either be an opaque access token or a JWT access token that list the /userinfo endpoint as an audience. You cannot use an ID Token (which happens to be a JWT) to call this endpoint.