In general, traditional web applications perform the end-user authentication and then, like you mentioned, proceed to create a cookie-based session containing the user identity which is used to derive all authorization decisions. What you’re doing is slightly different as you clearly separated the API aspects to an independent entity that stands on his own; there’s nothing wrong with this and it even allows other client application to be brought into the mix and all would be using the same API, however, this is still less common so finding sample code for your exact situation is less likely.
In your situation, here’s what I would do, assuming you have a test tenant where you can experiment with things as some of the steps imply changing global configuration:
- Register the MVC client application in the Clients section of the dashboard and name it
- Register the API resource server in the APIs section of the dashboard using an identifier/audience of
- Configure the API resource server to accept the tokens issued by your account; you can follow the ASP.NET Web API (OWIN) quickstart.
- Configure a Default Audience of
https://api.example.com in your account General settings. This means that every request will assume that an
audience parameter was specified with the value in question. This allows you to do a proof of concept of the whole system without having to focus first on the small details of passing an audience; we’ll have time for that later.
- Configure the
mvc-app to store the tokens resulting from the initial user authentication/authorization process alongside the user identity; in addition, you should request a refresh token to be issued by asking for the
offline_access scope. You can follow the associated quickstart step: https://auth0.com/docs/quickstart/webapp/aspnet-owin/03-storing-tokens
Having done the above you can already test the interactions between your system components as the default audience means the access token that
mvc-app receives is intended for
https://api.example.com and you can perform a refresh token exchange to obtain a new access token when that one expires.
As a final step, after confirming everything works as expected I would then focus on removing the need for the default audience and instead pass it as an additional parameter when the
mvc-app performs the initial request. From the link you provided, it seems the
RedirectToIdentityProvider notification would be a good candidate; probably something like: