Modifier

Partager via


Migrate public client applications from ADAL.NET to MSAL.NET

Warning

Azure Active Directory Authentication Library (ADAL) has been deprecated. While existing apps that use ADAL will continue to work, Microsoft will no longer release security fixes on ADAL. Use the Microsoft Authentication Library (MSAL) to avoid putting your app's security at risk.

This article describes how to migrate a public client application from Azure Active Directory Authentication Library for .NET (ADAL.NET) to Microsoft Authentication Library for .NET (MSAL.NET). Public client applications are desktop and mobile applications, including native (Win32) and WPF projects that call another service or API on behalf of a Microsoft Entra ID user. For more information about public client applications, see Authentication flows and application scenarios.

Migration steps

  1. Find the code by using ADAL.NET in your app.

    The code that uses ADAL in a public client application instantiates AuthenticationContext and calls an override of AcquireTokenAsync with the following parameters:

    • A resourceId string. This variable is the app ID URI of the web API that you want to call.
    • A clientId which is the identifier for your application, also known as App ID.
  2. After you've identified that you have applications that are using ADAL.NET, install the MSAL.NET NuGet package (Microsoft.Identity.Client) and update your project library references. For more information, see An introduction to NuGet.

  3. Update the code according to the public client application scenario. Some steps are common and apply across all the public client scenarios. Other steps are unique to each scenario.

    The public client scenarios are:

    • Web Account Manager, the preferred authentication approach for Windows applications, using the authentication broker component.
    • Interactive authentication, where the user is shown a web-based interface to complete the sign-in process.
    • Integrated Windows Authentication (IWA), where a user signs in using the same identity they signed into a Windows domain (for domain-joined or Microsoft Entra ID joined machines).
    • Username/password, where the sign-in occurs by providing a username/password credential. Microsoft does not recommend the username and password flow because the application will be asking a user for their password directly, which is an insecure pattern.
    • Device code flow, where a device with limited UX capabilities shows the consumer a device code to complete the authentication flow on an alternative device.

Interactive scenarios are where your public client application shows a login user interface hosted in a browser, and the user is required to interactively sign-in.

Find out if your code uses interactive scenarios

The ADAL code for your app in a public client application that uses interactive authentication instantiates AuthenticationContext and includes a call to AcquireTokenAsync, with the following parameters.

  • A clientId which is a GUID representing your application registration.
  • A resourceUrl which indicates the resource you are asking the token for.
  • A URI that is the reply URL.
  • A PlatformParameters object.

Update the code for interactive scenarios

The following steps for updating code apply across all the confidential client scenarios:

  1. Add the MSAL.NET namespace in your source code: using Microsoft.Identity.Client;.
  2. Instead of instantiating AuthenticationContext, use PublicClientApplicationBuilder.Create to instantiate IPublicClientApplication.
  3. Instead of the resourceId string, MSAL.NET uses scopes. Because applications that use ADAL.NET are preauthorized, you can always use the following scopes: new string[] { $"{resourceId}/.default" }.
  4. Replace the call to AuthenticationContext.AcquireTokenAsync with a call to IPublicClientApplication.AcquireTokenXXX, where XXX depends on your scenario.

In this case, we replace the call to AuthenticationContext.AcquireTokenAsync with a call to IPublicClientApplication.AcquireTokenInteractive.

Here's a comparison of ADAL.NET and MSAL.NET code for interactive scenarios:

ADAL

MSAL

var ac = new AuthenticationContext("https://login.microsoftonline.com/<tenantId>");
AuthenticationResult result;
result = await ac.AcquireTokenAsync("<clientId>",
"https://resourceUrl",
new Uri("https://ClientReplyUrl"),
new PlatformParameters(PromptBehavior.Auto));
var scopes = new[] { "User.Read" };

BrokerOptions options = new BrokerOptions(BrokerOptions.OperatingSystems.Windows);
options.Title = "My Awesome Application";

IPublicClientApplication app =
PublicClientApplicationBuilder.Create("YOUR_CLIENT_ID")
.WithDefaultRedirectUri()
.WithParentActivityOrWindow(GetConsoleOrTerminalWindow)
.WithBroker(options)
.Build();

AuthenticationResult result = null;

// Try to use the previously signed-in account from the cache
IEnumerable<IAccount> accounts = await app.GetAccountsAsync();
IAccount existingAccount = accounts.FirstOrDefault();

try
{    
if (existingAccount != null)
{
result = await app.AcquireTokenSilent(scopes, existingAccount).ExecuteAsync();
}
// Next, try to sign in silently with the account that the user is signed into Windows
else
{    
result = await app.AcquireTokenSilent(scopes, PublicClientApplication.OperatingSystemAccount)
.ExecuteAsync();
}
}
// Can't get a token silently, go interactive
catch (MsalUiRequiredException ex)
{
result = await app.AcquireTokenInteractive(scopes).ExecuteAsync();
}

The MSAL code shown above uses WAM (Web Account Manager) which is the recommended approach for authenticating users on Windows. If you wish to use interactive authentication without WAM, see Interactive Authentication.

Refer to the Using MSAL.NET with Web Account Manager (WAM) document for additional requirements to configure your application to use WAM.

Note

WAM is only available on Windows. If you are building a cross-platform application, you need to make sure that you have a fallback to interactive authentication without WAM.

MSAL benefits

Learn about MSAL library benefits in the Migrate applications to the Microsoft Authentication Library (MSAL) article.

Importance of logging with MSAL

Among its many capabilities, Microsoft Authentication Library (MSAL) has robust built-in logging features. Enabling logging in your applications ensures that you have a direct line of sight on any authentication issues and can both diagnose them easier for your own application and help the MSAL team quickly address potential problems. We strongly recommend that you enable logging for your applications when deployed in any production scenarios.

Troubleshooting

The following troubleshooting information makes two assumptions:

  • Your ADAL.NET code was working.
  • You migrated to MSAL by keeping the same client ID.

If you get an exception with the following message:

AADSTS90002: Tenant 'aaaabbbb-0000-cccc-1111-dddd2222eeee' not found. This may happen if there are no active subscriptions for the tenant. Check to make sure you have the correct tenant ID. Check with your subscription administrator.

You can troubleshoot the exception by using these steps:

  1. Confirm that you're using the latest version of MSAL.NET.
  2. Confirm that the authority host that you set when building the confidential client application and the authority host that you used with ADAL are similar. In particular, is it the same cloud (Azure Government, Microsoft Azure operated by 21Vianet, or Azure Germany)?

Next steps