1.2.0

Microsoft Identity Web 1.2.0 releases

Microsoft Identity Web 1.2.0 brings new features:

You can now specify scopes and app-permissions for GraphServiceClient

When you want to call Microsoft.Graph from your web app or web API, you need to:

• specify AddMicrosoftGraph in the startup.cs
• inject GraphServiceClient in the controller, or Razor page or Blazor page.

When you call AddMicrosoftGraph, you specify (by configuration or programmatically) the scopes to request initially. Until Microsoft.Identity.Web 1.2.0, you could not request more scopes when using a GraphServiceClient query, and you could not specify that the query needed app permissions (instead of delegated permissions)

With version 1.2.0, you can now:

• specify the delegated scopes to use by using .WithScopes(string[]) after the Request(). For instance:

   var users = await _graphServiceClient.Users
     .Request()
     .WithScopes("User.Read.All")
     .GetAsync();
     NumberOfUsers = messages.Count;

• specify that you want to use app permissions (that is https://graph.microsoft.com/.default) by using .WithAppOnly() after the Request(). For instance:

  var apps = await _graphServiceClient.Applications
       .Request()
       .WithAppOnly()
       .GetAsync();
       NumberOfApps = apps.Count;

  This later case requires the admin to have consented to these app-only permissions

Comfort methods for IDownstreamWebAPI

Microsoft.Identity.Web adds new generic extension methods applicable to the IDownstreamWebAPI interface to make it easier to call downstream APIs taking (or not) input parameters, and returning (or not) some output, and with a specified HTTP verb.

HTTP Verb	Extension Method
GET with input only	GetForUserAsync
GET with output only	GetForUserAsync
POST with input and output	PostForUserAsync<TOutput, TInput>
PUT with input only	PutForUserAsync
PUT with input and output	PutForUserAsync<TOutput, TInput>

See TodoListController.cs for an example of how these comfort methods are used to streamline the code in your controllers.

Integration with Azure App Services authentication of web Apps running with Microsoft.Identity.Web

When you deploy your app to Azure App Services, until now if you activated the Authentication/Authorization in App Services (EasyAuth), and also had authentication/authorization handled by Microsoft.Identity.Web, this did not work.

From version 1.2.0, the same code for your web app written with Microsoft.Identity.Web will work seamlessly with our without EasyAuth. Your web app can sign-in users and possibly call web APIs or Microsoft Graph. Indeed, Microsoft.Identity.Web now detects that the app is hosted in App Services, and uses that authentication. You can still sign-in users, and you can call web APIs provided you enabled them in App Services. For details on how to do that, see this tutorial: Configure App Service to return a usable access token

Normally your app should not need to know if it's hosted in App Services with Authentication or not, but if you want to propose a different UI, it can call AppServicesAuthenticationInformation.IsAppServicesAadAuthenticationEnabled to detect it.

Note that when Microsoft.Identity.Web detects EasyAuth, it automatically overrides the default authentication scheme to be AppServicesAuthenticationDefaults.AppServicesAuthenticationDefaults.

Possibility to challenge the user to request more scopes and claims

Microsoft.Identity.Web handles claims challenge exceptions automatically (See Handling incremental consent and conditional access for details)

However, in some advanced scenarios, you might need the application to request specific claims (they would still need to be known by Azure AD), you can now specify these claims in the Claims member of the TokenAcquisitionOptions. This request claims from the Microsoft identity platform /Token endpoint.

If you want to proactively request more claims or more scopes from the /Authorize endpoint you can use the ChallengeUser method of the MicrosoftIdentityConsentAndConditionalAccessHandler.

Support for Web API protected by ACLs and called by daemon apps

Daemon applications can validate a token based on application roles, or using the ACL-based authorization pattern to control tokens without a roles claim. To enable the ACL-based authorization, Microsoft Identity Web will no longer throw an exception when neither roles or scopes are not in the Claims provided you instruct it to do so. For this the MicrosoftIdentityOptions have a new boolean property named AllowWebApiToBeAuthorizedByACL which by passes the test for scopes or roles in the token. If you set this property to true in the appsettings.json or programmatically, this is your responsibility to ensure the ACL mechanism.

New MicrosoftIdentityIssuerValidatorFactoryService

public class AadIssuerValidatorOptions { public AadIssuerValidatorOptions(); public string HttpClientName { get; set; } }

AadIssuerValidator.GetIssuerValidator(string aadAuthority) is now obsolete with a clear message.

namespace Microsoft.Identity.Web.Resource { public class MicrosoftIdentityIssuerValidatorFactory { public MicrosoftIdentityIssuerValidatorFactory(IOptions aadIssuerValidatorOptions, IHttpClientFactory httpClientFactory); public AadIssuerValidator GetAadIssuerValidator(string aadAuthority); }