1
votes

I have the following setup: 2 Client applications (Xamarin Forms and WPF) and a single Web API (.NET Core 2.0). The client applications use the MSAL library to authenticate against Azure AD (Single Tenant application). After the client applications are authenticated they can call the Web API using their authentication token.

The Web API should authenticate this token ([Authorize] in the controllers) if it is valid and to know what user is calling the API. Authenticating the clients is no problem, using the AcquireTokenInteractive and AcquireTokenSilent methods this was made very easy.

When calling the Web API (using HttpClient we add the token in the headers: client.DefaultRequestHeaders.Add("Bearer", token);.

The Web API is (removed all test code) configured like this (and I know this is not enough) in the Startup.cs class:

services.AddAuthentication(AzureADDefaults.BearerAuthenticationScheme)
                .AddAzureADBearer(options => Configuration.Bind("AzureAd", options));

This is the template you get when creating a new project with Azure AD configured.

In the Azure AD Portal we have configured out Application and the ID's (TentantId, ClientId/ApplicationId) are configured on the client applications and the Web API.

We have done reseach in the On-Behalf-Of flow but I'm not sure that this is the flow we need.

The application is registered as a Single tentant application and the Suggested Redirect Uriis set to msal[UNIQUE_ID_I_REMOVED_FOR_SECURITY]://auth should this be set to https://login.microsoftonline.com/common/oauth2/nativeclient

We do not have experience with the Azure AD flow and could use some help. If anybody can point me in the correct direction with links, documentation, sample code it would be greatly appreciated.

Thank you for any help.

1

1 Answers

1
votes

This sample shows how to call a core API from a WPF application using the V1 endpoint or this one if using V2 endpoint. The API needs to know 1) who issued the token (authority) so it can get its issuer name and signing keys 2) its audience id so it can validate whether the incoming token's audience is for it (usually a guid or uri). OBO flow would become only relevant to you if your API needs to call yet another API on-behalf of the original user: the flow allows you to exchange a token you recived (API1) for a token to another API (API2) preserving information about the original user.