-
Notifications
You must be signed in to change notification settings - Fork 367
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.
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 it is error prone, because AAD might throttle you.
Even if AuthenticationResult
returns the Expiry of the token, you should not handle the expiration and the refresh of the access tokens on your own. MSAL.NET does this for you.
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
{
// will handle expired Access Tokens by fetching new ones using the Refresh Token
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
- 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