I have both a C# WebAPI2 (using .NET CORE) working with an entirely separate project which is using WebAPP (.NET CORE).
I can’t find an example of using Auth0 with this setup. I can’t get user claims in “helper classes” because it requires you to extend Controllers do so. This means, I always have to use a Controller in order to get the bearer token to call the WebAPI. But in some circumstances (such as registering a user) I don’t want to use a controller.
Do you have an example of WebAPP’s using WebAPI with Auth0 ?
While we don’t have a sample of both type of applications working together as one solution (there would be just too many combinations to cover), there are a few important details to keep in mind:
If the web app will be accessing the API backend, the important bit is that when asking Auth0 to authenticate the user, you will need to pass the audience parameter with the API identifier, so that the access_token returned by Auth0 can be used to access the API. Passing additional parameters to the /authorize endpoint explains how to add the audience parameter, but it basically means handling the OnRedirectToIdentityProvider event in the OpenIDConnectOptions:
var options = new OpenIdConnectOptions("Auth0")
{
...] // other options omitted for brevity
Events = new OpenIdConnectEvents
{
...] // other events omitted
OnRedirectToIdentityProvider = context =>
{
// set your API audience here
context.ProtocolMessage.SetParameter("audience", "YOUR_API_IDENTIFIER");
return Task.CompletedTask;
}
With this in place, Auth0 will return an access_token that you can use to invoke the API. You might want to store the access token in the user’s identity for later use, to do so look at this sample.
Both the CookieAuthentication middleware used in the web sample and the JwtBearerAuthentication middleware used in the WebAPI sample will set the ClaimsPrincipal for the current web request. Controllers give you easy access to it with the User property. It’s not always a good idea to access this information globally, but if you absolutely need the information from a helper class you can use System.Security.Claims.ClaimsPrincipal.Current. This returns Thread.CurrentPrincipalby default, but that can be changed with the ClaimsPrincipalSelector delegate.
The problem is that using .NET CORE you can’t call a Controller from another class (Particularly with Dependency injection). That means your OnTicketReceived can’t call the CORE WEBAPI because you have to instantiate the controller in order to get the Bearer token.
How would I make calls from the Website to my API to insert a user record on OnTicketReceived if these are not practices recommended when using DI?
I know you have two examples, but what I’m saying is that they actually don’t work together. Or at least I can’t get them to work together…
I can have the WebAPP call the WebAPI using coined instructions … thats not the problem …
I started looking into Hooks (which would solve the issue), but it seems like your hooks have bugs as well - not calling out on social media connections. That means I will get registered users that won’t be registered on my system.
Using my own DB to store is also not really an option, because why would I use your service if I have to implement my own storage?
If you need the user’s claims on the OnTicketReceived event, you can use context.Principal. If you need the user information on the WebAPI side, however, the situation is different. On the WebAPI side you will receive an access_token with only the sub (user id) claim about the user. If you need to get additional information about the user, you would call the /userinfo endpoint as shown in this example.
User registers with the WebAPP. I need to save the UserID locally on our database so I can reference the user throughout the application via the UserID that you originally send.
I need a way to “Register” the user locally so I have the UserID from Auth0.
By using the HOOK instead, the flow could look like this - which is “better”, but its really difficult to debug locally because your Webtask Editor, gives 500 errors unless you actually register. I have to register a user to test the code every time.
If I decide to go with a HOOK, I would then need to include the bearer token in the call to my API so its secure (hopefully your hook does this? I haven’t got that far with it yet)
I also would run into a situation where the user can’t access my system until your hook is fired - which is also a giant nightmare if your site goes down, so does mine and I potentially lose a user. Or I can also get into a problem where your system doesn’t fire the API call to my system before the user actually logs in. Sit and Wait problem.
Here are some thoughts on the use case. I don’t think there’s a “right” choice, but it’s good to know the alternatives, pros and cons.
The OnTicketReceived event happens on every login (not just on signups), so if you plan to save the user there you will need to take into account that the user might have already been registered before. You can certainly access the access_token when handling this event, take a look at Storing tokens for guidance.
The Pre-User registration hook seems suitable because it’s executed synchronously in the pipeline: the registration process will not finish until the hook ends execution. The Post-User registration, on the other hand, executes asynchronously so there’s no guarantee that the user record will be in the database by the time the user logs in.
As for the situation where the user can’t access the system because the registration process didn’t execute (regardless of where it is implemented), if this is a major concern I would recommend to architecture the system so that it is resilient to those events. As in “Does the user exist in the database? No? No worries, keep going!”.
If you decide to go with hooks and need authenticated access to the WebAPI, you should look into the client credentials grant model, which is suitable when a backend service (the hook) calls another backend service (the WebAPI). By following this model, you will provide the hook with a client id and client secret that the hook will be able to exchange for an access token to call your WebAPI.