As per the question, I can’t figure out how to add the audience required to access an Auth0 API in a .NET 4.5.2 MVC application. As all the examples use cookie authentication over token authentication, it is unclear how best to do this. Both my MVC app and API app are checked as being OIDC compliant and both are using RS256.
I’ve tried using the events mentioned here to try and add the audience manually, but it’s not working for me and perhaps I’m not doing it right.
I’m aware that there are events in Auth0AuthenticationOptions.Provider that may provide the solution I need, but again, I don’t think I understand enough about how Auth0 works and the settings required in order to make this work.
It seems like it should be simple enough, but sadly all the working examples are purely for .NET Core and there is nothing (that I can find) to illustrate how to successfully get a .NET Framework MVC application to communicate with a .NET Framework Web API securely using Auth0 and JWTs.
1 Like
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
mvc-app.
- Register the API resource server in the APIs section of the dashboard using an identifier/audience of
https://api.example.com.
- 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:
context.ProtocolMessage.SetParameter("audience", "https://api.example.com/");