Asp-Net-Core WebApi Authentication using Azure ActiveDir oAuth2.0 JWT Token Microsoft Graph

Question

I am emulating a SPA (single page application) by adapting this .net core asp-net-core template (https://github.com/TrilonIO/aspnetcore-Vue-starter/blob/master/content/Vue2Spa.sln)

I am able to authenticate the user using MSAL for microsoft graph.

How can I use that same token I used for Microsoft graph for my API (same project, no CORS necessary).

Everything I try fails.

What should StartUp look like? I don't want any cookie authentication, i have the AccessToken ready to pass as a JWT token.?

I'd like to use [Authorize] in my API controllers.

SPA --> Gets Token (it's based off my clientId etc), pass token 'Bearer eyJ0eXAiO....' with AJAX calls to my api controllers.

Answer 1

I was able to do it using the ID token that I created with the MSAL library.

Javascript: return myMSALObj.loginPopup(requestObj).then(function (loginResponse) { loginResponse.Token});

You can then take that token and pass it to the API.

in StartUp.cs

       public void ConfigureServices(IServiceCollection services)
       {
       services.AddAuthentication(options =>
       {
       options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
       options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
       }).AddJwtBearer(options =>
       {
       options.Authority = "https://sts.windows.net/tenantId/v2.0";
       options.Audience = clientId;
       options.TokenValidationParameters.ValidateLifetime = true;
       });

       services.AddAuthorization();

       // Add framework services.
       services.AddMvc()
       .SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
       }```

Answer 2

You will not be able to use the token that was acquired for Microsoft Graph API, to call your API.

Token that you acquire is valid for a specific resource, which can be identified by the aud claim value (i.e. audience). You can read more about aud claim and how it specifies the intended recipient for the token here - Microsoft identity platform access tokens

If you decode your current bearer token using https://jwt.ms or https://jwt.io you will see that your token for Microsoft Graph API will have an audience like https://graph.microsoft.com so it's not really meant for your application.

You will need to acquire a token explicitly for your api.

You can find detailed code samples here Microsoft Identity Platform Code Samples (v2.0 endpoint) for Single Page Applications. Take a look at this one for SPA calling it's own api - JavaScript Single Page Application with an ASP.NET backend, using msal.js. This one uses clientid itself for scope.

Here is another one which (not SPA), but shows how to define your custom api scopes and then use them from client in case of API and client applications being separate - Calling an ASP.NET Core Web API from a WPF application using Azure AD V2. You can do that from Expose an API section under your app registration in Azure Portal.

Answer 3

I don't know much about MSAL in comparison to ADAL, but I believe one difference is the Azure endpoint. It is now changed to version 2 instead. As recommended by Microsoft, when authenticating users against Azure AD, the suggested approach is to use oauth 2.0 implicit flow. More info can be found here.

Your steps in acquiring token for Microsoft Graph involve a bit of time configuring. You should register both of your front end and the API in the Azure app registration Within the front-end app, you enable implicit flow, you give it some permissions to interact with graph api. This is required in order to use your existing token to acquire another token for Microsoft Graph. (And you can do the same thing for any other APIs, eg. CRM API, Sharepoint API)

Once you have this configured, all you need to do is to do another post request(you must include the JWT token you retrieved earlier in the request header) to https://graph.microsoft.com to acquire the token. Depending on how you grant permissions to front-end, the token can be used within a given scope that you set in the app registration.

You maybe wondering why use implicit flow? It’s because every time your front-end app sends requests to the backend API, the JWT token that you retrieved at signed in can be used to authenticate against your API. This way, only your front end can make calls to the api.