-
Notifications
You must be signed in to change notification settings - Fork 366
Client credential flows
MSAL is a multi-framework library. All Confidential Client flows, including the one presented here, are available on: .NET Core, .NET Desktop .NET Standard. They are not available on the mobile platforms (UWP, Xamarin.iOS, and Xamarin.Android) as these only support public client applications which don't know how to prove the application's identity to the Identity Provider. This secure connection can be achieved on web app or web API back-ends by deploying a certificate.
MSAL.NET supports 2 types of client credentials:
- Application secrets
- Certificates
For advanced scenarios, 2 more types of credentials can be used. See details at Client assertions
- Signed client assertions
- Certificate + additional claims to be sent
These client credentials need to be:
- registered with Azure AD
- Passed in the constructors of
ConfidentialClientApplication
in your code
Then you can call AcquireTokenForClient
.
You can register your application secrets either through the interactive experience in the Azure portal, or using command-line tools (like PowerShell)
The management of client credentials happens in the certificates & secrets page for an application:
- the application secret (also named client secret) is generated by Azure AD during the registration of the confidential client application when you select New client secret. At that point, you must copy the secret string in the clipboard for use in your app, before selecting Save. This string won't be presented any longer.
- the certificate is uploaded in the application registration using the Upload certificate button
The active-directory-dotnetcore-daemon-v2 sample shows how to register an application secret or a certificate with an Azure AD application:
- For details on how to register an application secret, see AppCreationScripts/Configure.ps1
- For details on how to register a certificate with the application, see AppCreationScripts-withCert/Configure.ps1
In MSAL.NET client credentials are passed as a parameter at the application construction
Then, once the confidential client application is constructed, acquiring the token is a question of calling overrides of AcquireTokenForClient
, passing the scope, and forcing or not a refresh of the token.
The following code snippet shows how to acquire a token to call the Microsoft Graph. It uses the application permissions that were statically registered for the application. For more information, see AuthenticationConfig.cs
It is important to specify the tenant. Use of common
or organizations
is ambiguous and will be disallowed at some point in the future.
var app = ConfidentialClientApplicationBuilder.Create(config.ClientId)
.WithAuthority(AzureCloudInstance.AzurePublic, "{tenantID}")
.WithClientSecret(config.ClientSecret)
.Build();
X509Certificate2 certificate = ReadCertificate(config.CertificateName);
var app = ConfidentialClientApplicationBuilder.Create(config.ClientId)
.WithAuthority(AzureCloudInstance.AzurePublic, "{tenantID}")
.WithCertificate(certificate)
.Build();
With client credentials flows the scopes is ALWAYS of the shape "resource/.default", as the application permissions need to be set statically (in the portal or by PowerShell), and then granted by a tenant administrator
string[] scopes = new string[] { "https://graph.microsoft.com/.default" };
AuthenticationResult result = null;
try
{
result = await app.AcquireTokenForClient(scopes)
.ExecuteAsync();
}
catch(MsalServiceException ex)
{
// Case when ex.Message contains:
// AADSTS70011 Invalid scope. The scope has to be of the form "https://resourceUrl/.default"
// Mitigation: change the scope to be as expected
}
Instead of a client secret or a certificate, the confidential client application can also prove its identity using client assertions. This advanced scenario is detailed in Client assertions
AcquireTokenForClient
uses the application token cache (not the user token cache)
Don't call AcquireTokenSilent
before calling AcquireTokenForClient
as AcquireTokenSilent
uses the user token cache. AcquireTokenForClient
checks the application token cache itself and updates it.
The scope to request for a client credential flow is the name of the resource followed by /.default
. This notation tells Azure AD to use the application level permissions declared statically during the application registration. Also these API permissions must be granted by a tenant administrator
ResourceId = "someAppIDURI";
var scopes = new [] { ResourceId+"/.default"};
var result = app.AcquireTokenForClient(scopes);
In the case where your confidential client application uses only client credentials flow, you don't need to pass a reply URL passed in the constructor.
Sample | Platform | Description |
---|---|---|
active-directory-dotnetcore-daemon-v2 | .NET Core 2.1 Console |
![]() ![]() |
active-directory-dotnet-daemon-v2 | ASP.NET MVC |
![]() |
You can find more information in:
- The reference documentation for ConfidentialClientApplication Constructors and AcquireTokenForClientAsync
- The protocol documentation: Azure Active Directory v2.0 and the OAuth 2.0 client credentials flow
Vanity URL: https://aka.ms/msal-net-client-credentials
- Home
- Why use MSAL.NET
- Is MSAL.NET right for me
- Scenarios
- Register your app with AAD
- Client applications
- Acquiring tokens
- MSAL samples
- Known Issues
- Acquiring a token for the app
- Acquiring a token on behalf of a user in Web APIs
- Acquiring a token by authorization code in Web Apps
- AcquireTokenInteractive
- WAM - the Windows broker
- .NET Core
- Maui Docs
- Custom Browser
- Applying an AAD B2C policy
- Integrated Windows Authentication for domain or AAD joined machines
- Username / Password
- Device Code Flow for devices without a Web browser
- ADFS support
- High Availability
- Regional
- Token cache serialization
- Logging
- Exceptions in MSAL
- Provide your own Httpclient and proxy
- Extensibility Points
- Clearing the cache
- Client Credentials Multi-Tenant guidance
- Performance perspectives
- Differences between ADAL.NET and MSAL.NET Apps
- PowerShell support
- Testing apps that use MSAL
- Experimental Features
- Proof of Possession (PoP) tokens
- Using in Azure functions
- Extract info from WWW-Authenticate headers
- SPA Authorization Code