-
Notifications
You must be signed in to change notification settings - Fork 344
do not
This page gathers recommendations about does and don't
Even if you can have a look at what is contained in an Access token (for instance using https://jwt.ms), for education, or debugging purposes, you should never parse an access token part of your client code. The access token is only meant for the Web API (resource) it's acquired for, and this Web API is the only one should crack open it. Most of the time the Web apis will use a middleware layer (for instance Identity model extension for .NET in .NET), as this is complex code, about the protection of your web apps and Web apis, and you don't want to introduce security vulnerabilities by forgetting some important paths.
Even if AuthenticationResult
returns the Expiracy of the token, you don't need to handle the expiration and the refresh of the access tokens on your own. MSAL.NET caches any tokens you get.
For flows retrieving tokens for a user account, you'd want to use the recommended pattern as these write tokens to the user token cache, and tokens are retrieved and refreshed (if needed) silently by AcquireTokenSilent
AuthenticationResult result;
try
{
result = await AcquireTokenSilent(scopes).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
result = AcquireTokenXXXX(scopes, ..).WithXXX(…).ExecuteAsync();
}
Finally if you use AcquireTokenForClient
(client credentials) you don't need it to bother of the cache as this method not only stores tokens to the application cache, but it also looks them up and refreshes them if needed (this is the only method interacting with the application token cache: the cache for tokens for the application itself)
MSAL.NET
The standard pattern of acquiring tokens is:
acquire token silent (from the cache)
if that doesn't work, acquire a token from the AAD
If you skip step 1, your app may be asking for tokens from AAD very often. This provides a bad user experience, because it is slow and is error prone, because AAD might throttle you.
- 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
- 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
- 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
- High Availability
- 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