Sources

During the sign-in experience, you may encounter errors about consents, Conditional Access (MFA, Device Management, Location-based restrictions), token issuance and redemption, and user properties. The following section provides more details about error handling for your app. … If MsalServiceException is thrown, try Authentication and authorization error codes to see if the code is listed there. If MsalUIRequiredException is thrown, it's an indication that an interactive flow needs to happen for the user to resolve the issue. In public client apps such as desktop and mobile app, this is resolved by calling `AcquireTokenInteractive`, which displays a browser. In confidential client apps, web apps should redirect the user to the authorization page, and web APIs should return an HTTP status code and header indicative of the authentication failure (401 Unauthorized and a WWW-Authenticate header). … |Exception|Error code|Mitigation| |--|--|--| |MsalUiRequiredException|AADSTS65001: The user or administrator hasn't consented to use the application with ID '{appId}' named '{appName}'. Send an interactive authorization request for this user and resource.|Get user consent first. If you aren't using .NET Core (which doesn't have any Web UI), call (once only) `AcquireTokenInteractive`. If you're using .NET core or don't want to do an `AcquireTokenInteractive`, the user can navigate to a URL to give consent: `https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={clientId}&response_type=code&scope=user.read`. to call `AcquireTokenInteractive`: `app.AcquireTokenInteractive(scopes).WithAccount(account).WithClaims(ex.Claims).ExecuteAsync();`| |MsalUiRequiredException|AADSTS50079: The user is required to use multifactor authentication (MFA).|There's no mitigation. If MFA is configured for your tenant and Microsoft Entra ID decides to enforce it, fall back to an interactive flow such as `AcquireTokenInteractive`.| |MsalServiceException|AADSTS90010: The grant type isn't supported over the */common* or */consumers* endpoints. Use the */organizations* or tenant-specific endpoint. You used */common*.|As explained in the message from Microsoft Entra ID, the authority needs to have a tenant or otherwise */organizations*.| … ### MsalUiRequiredException One of common status codes returned from MSAL.NET when calling `AcquireTokenSilent()` is `MsalError.InvalidGrantError`. This status code means that the application should call the authentication library again, but in interactive mode (AcquireTokenInteractive or AcquireTokenByDeviceCodeFlow for public client applications, do have a challenge in Web apps). This is because additional user interaction is required before authentication token can be issued. Most of the time when `AcquireTokenSilent` fails, it is because the token cache doesn't have tokens matching your request. Access tokens expire in 1 hour, and `AcquireTokenSilent` tries to fetch a new one based on a refresh token (in OAuth2 terms, this is the "Refresh Token' flow). This flow can also fail for various reasons, for example if a tenant admin configures more stringent sign-in policies. … |Classification|Meaning|Recommended handling| |--|--|--| |UserPasswordExpired|User's password has expired.|Call AcquireTokenInteractively() so that user can reset their password.| |PromptNeverFailed|Interactive Authentication was called with the parameter prompt=never, forcing MSAL to rely on browser cookies and not to display the browser. This has failed.|Call AcquireTokenInteractively() without Prompt.None| |AcquireTokenSilentFailed|MSAL SDK doesn't have enough information to fetch a token from the cache. This can be because no tokens are in the cache or an account wasn't found. The error message has more details.|Call AcquireTokenInteractively().| … ## Conditional Access and claims challenges When getting tokens silently, your application may receive errors when a Conditional Access claims challenge such as MFA policy is required by an API you're trying to access. The pattern for handling this error is to interactively acquire a token using MSAL. This prompts the user and gives them the opportunity to satisfy the required Conditional Access policy. In certain cases when calling an API requiring Conditional Access, you can receive a claims challenge in the error from the API. For instance if the Conditional Access policy is to have a managed device (Intune) the error will be something like AADSTS53000: Your device is required to be managed to access this resource or something similar. In this case, you can pass the claims in the acquire token call so that the user is prompted to satisfy the appropriate policy. When calling an API requiring Conditional Access from MSAL.NET, your application needs to handle claim challenge exceptions. This appears as an MsalServiceException where the Claims property won't be empty. To handle the claim challenge, use WithClaims(String).

## INCREMENTAL AND DYNAMIC CONSENT One of the biggest issues with v1, especially for multi-tenant applications, is that you must define every permission your app will ever need in advance. And the user must accept all of these required permissions. So for example, if your application offers an optional calendar integration to Office 365, you would have to require the access to the user's calendar even if your app never used it for that user. *There are ways around that by using a second application of course.* With v2, you can specify which scopes you need when redirecting the user to authenticate. … ## CURRENT LIMITATIONS AND PROBLEMS In this part we will look at some limitations of the v2 endpoint as well as problems we have faced. **These limitations are going to be removed as time goes by though!** No official schedule exists for when those features will come. But they will be added. Perhaps the biggest limitation currently is the rather **small set of APIs that apps can use**. Your app can use: 1. Its own API 2. Outlook Mail, Calendar, and Contacts REST APIs 3. Microsoft Graph API (which contains the Outlook APIs) If you want to use any other API, then currently your only option is to use the v1 endpoint. Also, you **cannot build stand-alone Web APIs currently**. Only an app with the same application ID can request an access token for the API. So you cannot register an API and use it from another app currently. If you want to read about the full set of current limitations, you can check the documentation: Azure AD v2 endpoint limitations. The API for token caches in MSAL.NET is a little bit *funky*. Firstly, the … } <span class="kw">catch</span> (Exception e) { <span class="kw">throw</span>; } _cache.<span class="fu">HasStateChanged</span> = <span class="kw">false</span>; } }</code> So now we cannot take advantage of the asynchronous APIs available on the distributed cache, and we are blocking the thread until we get a response from the cache. This same issue exists in ADAL as well. It is also important to remember that **v1 applications are currently not compatible with the v2 endpoint**. Same goes the other way, you cannot use the v1 endpoint from a v2 application. A migration path for v1 applications does not exist yet. However v2 application management is planned to be merged with v1 application management in Azure Portal. Once that happens, current v1 applications will be able to use the v2 endpoint, and there will be a documented migration path. One problem that we run into some time ago, but did not run into anymore, was that consent was not being granted after logging in and consenting to the permissions. It took a while (like 15 seconds) for the consent to be done. This issue seems to have been fixed.

1. [What are the differences between supported audiences and account types?](#what-are-the-differences-between-supported-audiences-and-account-types) **[B2C](#b2c)** 1. [My B2C application has more than one user-flow/policy. How do I work with multiple policies in MSAL.js?](#my-b2c-application-has-more-than-one-user-flowpolicy-how-do-i-work-with-multiple-policies-in-msaljs) 1. [How can I implement password reset user flow in my B2C application with MSAL.js?](#how-can-i-implement-password-reset-user-flow-in-my-b2c-application-with-msaljs) 1. [I logged out of my application. Why am I not asked for credentials when I try to log back in?](#i-logged-out-of-my-application-why-am-i-not-asked-for-credentials-when-i-try-to-log-back-in) … [using MSAL.js with IE](https://github.com/AzureAD/microsoft-authentication-library-for-js/wiki/Using-msal.js-with-Internet-Explorer). There are certain known issues and mitigations documented for Safari, IE and Edge. ... MSAL.js integrates with the Azure AD v2.0 endpoint, whereas ADAL.js integrates with the Azure AD v1.0 endpoint. The v1.0 endpoint supports work and school accounts, but not personal Microsoft accounts. The v2.0 endpoint combines work, school and personal Microsoft accounts into a single authentication system. Additionally, with MSAL.js you can also achieve authentication for Azure AD B2C. … Obtaining a cached access token via `acquireTokenSilent` is still possible, however, if the token is expired the service will throw an "X-Frame Options DENY" error when MSAL attempts to renew it. When this happens your application must catch this error and fallback to calling an interactive method (`acquireTokenRedirect` or `acquireTokenPopup`) ## How can I implement password reset user flow in my B2C application with MSAL.js? … An example flow can be seen in the [working with B2C](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/working-with-b2c.md) doc. # Common Issues ## How to avoid page reloads when acquiring and renewing tokens silently? MSAL.js uses hidden iframes to acquire and renew tokens silently in the background. … Redirect loops occur most commonly when an app automatically triggers a `loginRedirect` call on page load. Your app should first verify a user is signed-in before attempting to login. ```javascript if (!msalObj.getAccount()) { msalObj.loginRedirect(request); } else { // User signed in! } ``` ### Solutions - If using msal-angular and your app relies on the broadcast events, ensure your app calls `handleRedirectCallback()` on the page that handles the response containing the token. - Set `navigateToLoginRequestUrl: false` in your msal config.

Effective May 1, 2025, Azure AD B2C will no longer be available to purchase for new customers. ... Developers can adopt latest releases of MSAL and stay up to date. See how to increase resilience of authentication and authorization in your applications. Where possible, avoid implementing your own authentication stack. Instead, use well-established libraries. … Migrate your application from MSAL.js 1.x to MSAL.js 2.x to realize the resiliency of web applications. The implicit flow doesn't result in a refresh token. The SPA can use a hidden `iframe` to perform new token requests against the authorization endpoint if the browser has an active session with the Azure AD B2C.

1. How to get single sign-on in my application with MSAL.js? 2. How can my application recognize a user after sign-in? How do I correlate users between applications? 3. Troubleshooting single sigon-on ** Accounts ** ... Why am I not asked for credentials when I try to log back in? 5. Why am I not signed in when returning from an invite link? 6. Why is there no access token returned from acquireTokenSilent? 7. What should I do if I believe my issue is with the B2C service itself rather than with the library **Common Issues** 1. Why is MSAL throwing an error? … ### Known Issues with Certain Browsers There are certain known issues and mitigations documented for the following browsers: - Browsers that block 3rd Party Cookies (i.e. Safari, Chrome Incognito, Firefox Private) … ## Will MSAL 2.x support B2C? MSAL.js v2 supports B2C of October 2020. ## Is MSAL.js 2.x compatible with Azure App Proxy? Unfortunately, at this time MSAL.js 2.x is not compatible with Azure App Proxy . Single-page applications will need to use MSAL.js 1.x as a workaround. We will post an update when this incompatibility has been fixed. See this issue for more information. … has resolved before invoking any other MSAL method. If your app was not loaded as a result of a redirect operation ``` handleRedirectPromise ``` will immediately return ``` null ``` . Please review one of our samples ( for instance ) to see the redirect flow in action. ## How can I support authentication with personal Microsoft accounts only? Simply set your ``` authority ``` in your MSAL app configuration to **consumers** tenant e.g. https://login.microsoftonline.com/consumers . … ## Troubleshooting Single Sign-On The following is a list of common causes for SSO failures when using MSAL Browser: ### 1. The user has blocked third-party cookies in their browser Silent SSO requires third-party cookie access so the authentication service can persist a user's session accross tabs. If third-party cookies are blocked, silent SSO will fail and interaction will be required. ### 2. There is a content security policy or HTTP header blocking the iframe from loading your redirect URI page When using ``` ssoSilent ``` , the service will attempt to load your redirect URI page in an invisible embedded iframe. Content security policies and HTTP header values present in your app's redirect URI page response, such as … ### 3. The configured redirecUri is a different origin as the calling page Because of cross-origin request limitations, in order for MSAL to have access to the hidden iframe's ``` window.location.href ``` property, the ``` redirectUri ``` configured in the ``` ssoSilent ```

- All Microsoft support and development for ADAL, including security fixes, ended on June 30, 2023. ... MSAL is designed to enable a secure solution without developers having to worry about the implementation details. It simplifies and manages acquiring, managing, caching, and refreshing tokens, and uses best practices for resilience. We recommend you use MSAL to increase the resilience of authentication and authorization in client applications that you develop. … ... |Proactively refresh and revoke tokens based on policy or critical events for Microsoft Graph and other APIs that support Continuous Access Evaluation (CAE).| | |

## Conditional Access and claims challenges When getting tokens silently, your application may receive errors when a Conditional Access claims challenge such as MFA policy is required by an API you're trying to access. The pattern for handling this error is to interactively acquire a token using MSAL. This prompts the user and gives them the opportunity to satisfy the required Conditional Access policy. In certain cases when calling an API requiring Conditional Access, you can receive a claims challenge in the error from the API. For instance if the Conditional Access policy is to have a managed device (Intune) the error will be something like AADSTS53000: Your device is required to be managed to access this resource or something similar. In this case, you can pass the claims in the acquire token call so that the user is prompted to satisfy the appropriate policy. When calling an API requiring Conditional Access from MSAL.NET, your application needs to handle claim challenge exceptions. This appears as an MsalServiceException where the Claims property won't be empty. To handle the claim challenge, use WithClaims(String). ## Retrying after errors and exceptions You're expected to implement your own retry policies when calling MSAL. MSAL makes HTTP calls to the Microsoft Entra service, and occasionally failures can occur. For example the network can go down or the server is overloaded. ### HTTP 429 When the Service Token Server (STS) is overloaded with too many requests, it returns HTTP error 429 with a hint about how long until you can try again in the `Retry-After` response field. ### HTTP error codes 500-600 MSAL.NET implements a simple retry-once mechanism for errors with HTTP error codes 500-600. MsalServiceException surfaces `System.Net.Http.Headers.HttpResponseHeaders` as a property `namedHeaders`. You can use additional information from the error code to improve the reliability of your applications. In the case described, you can use the

### Downsides and Limitations Despite its many advantages, MSAL is not without its limitations. Understanding the source of authentication is crucial, and MSAL may not suit all architectures, especially those heavily reliant on microservices. Furthermore, while MSAL excels in managing authentication and authorization, it does not fully address access control issues—specifically, whether a user should have access to certain functions or data within an application. ### Strategies for Using MSAL Effectively To maximize the benefits of MSAL, developers should consider the following strategies: - Clearly understand the authentication needs of your application to choose the right authentication method offered by MSAL. - Work closely with your IT department to manage claims and tokens effectively, especially if modifications are required that MSAL does not natively support.

Exceptions in MSAL.NET are intended for app developers to troubleshoot and not for displaying to end-users. Exception messages are not localized. MSAL throws `MsalClientException` for things that go wrong inside the library (e.g. bad configuration) and `MsalServiceException` for things that go wrong service side or in the broker (e.g. a secret expired). Client exceptions have an error code which you can use to handle the exception. The error codes are explained in the MsalError class. ### Common exceptions - User cancelled authentication (public client only) When calling `AcquireTokenInteractive`, a browser or the broker is invoked to handle user interaction. If the user closes this process or if they hit the browser back button, MSAL generates an `MsalClientException` with the error code `authentication_canceled` ( `MsalError.AuthenticationCanceledError`). On Android, this exception can also occur if a browser with tabs is not available. - HTTP errors ### HTTP Exceptions Developers are expected to implement their own retry policies when calling MSAL. MSAL makes HTTP calls to the AAD service, and occasional failures can occur, for example the network can go down or the server is overloaded. HTTP 5xx status code responses are retried once. MSAL does not rethrow HTTP exceptions as MsalException. See also Simple retry for errors with HTTP error codes 500-600 and Http 429 (Retry After) … #### MsalUiRequiredException The "Ui Required" is proposed as a specialization of `MsalServiceException` named `MsalUiRequiredException`. This means you have attempted to use a non-interactive method of acquiring a token (e.g. AcquireTokenSilent), but MSAL could not do it silently. this can be because: - you need to sign-in - you need to consent - you need to go through a multi-factor authentication experience. The remediation is to call `AcquireTokenInteractive` try { app.AcquireTokenXXX(scopes, account) .WithYYYY(...) .ExecuteAsync() } catch(MsalUiRequiredException ex) { app.AcquireTokenInteractive(scopes) .WithAccount(account) .WithClaims(ex.Claims) .ExcecuteAsync(); } ### Handling Claim challenge exceptions in MSAL.NET In some cases, when the Azure AD tenant admin has enabled conditional access policies, your application will need to handle claim challenge exceptions. This will appear as an `MsalServiceException` which `Claims` property won't be empty. For instance if the conditional access policy is to have a managed device (Intune) the error will be something like `AADSTS53000: Your device is required to be managed to access this resource` or something similar. To handle the claim challenge, you will need to use the .WithClaim() method of PublicClientApplicationBuilder class as shown above. ### Getting started with MSAL.NET - Home

The presentation begins with a brief overview of MSAL, outlining its role in simplifying the authentication process across various platforms. Despite the widespread understanding of MSAL among the audience in 2025, Ben feels compelled to reiterate its foundational aspects before delving into more technical discussions, particularly concerning assembly load context (ALC) issues that arise during its implementation in PowerShell modules like AZ and MS Graph. These modules have incorporated their own versions of MSAL, leading to potential conflicts when users attempt to work with multiple modules in the same session. Ben articulates the frustrations and complications associated with overlapping library versions, outlining scenarios where users encounter silent failures or misleading error messages. He stresses the urgency of addressing these issues through a unified library approach to minimize compatibility problems. This leads to a critical juncture in the lecture where the discussion shifts towards alternatives to MSAL. ... A key takeaway from the session is the notion that while it is technically feasible to write your own authentication logic, it is rarely recommended outside of specific contexts. Ben shares practical examples where developers may feel compelled to create their own solutions. He highlights several authentication flows, including interactive authentication, device code flow, client secret flow, and managed identity scenarios, showcasing both the simplicity and potential pitfalls of custom implementations. ... Uh and then we're going {ts:142} to talk about ALC or assembly load context and essentially why I believe and this is just a personal opinion uh {ts:148} that there are some issues with how we've implemented authentication uh in PowerShell and in the modules that we

And I don't think you need to avoid MEL, but {ts:208} there are some problems with how it's implemented in PowerShell that I personally believe could be solved and {ts:214} need to be solved by the big guys. Uh, because this is such an important uh this is such an … You've got to set up {ts:286} all these things, you know, configure a billion different resources and you just don't. It's it's it's two steps. The {ts:297} problem is kind of with PowerShell, kind of with how it's been implemented. So, as I said, most … {ts:367} after the other in the same profile, things get weird. They fail, but sometimes they fail silently. So it just {ts:375} doesn't work and it continues to use whatever the previous version of that library was that you were using. In the {ts:381} scenario of the a modules and the MS graph modules, they they are maintained by different teams. they cannot keep up … It's a very bad idea. Functionally {ts:637} that works though. You can get a token. Don't write in VB. It's very bad. That's what it stands {ts:646} for. Okay. So because we don't have a native module that uh abstracts the ML library in a sort of a unified way that … {ts:999} what is happening which is why I don't like it. You know, abstraction is good to a point. If it makes it so that you {ts:1006} can't actually tell what's happening, I think it's detrimental uh for us at the end of the day because as I said, if … {ts:1988} application so that you can retrieve it and that's where credential leakage comes into play and that's why I don't {ts:1992} really like this solution. This can be swapped out for certificate- based authentication as well. Um but you know {ts:1998} the same thing applies there is the potential that that could be leaked as well.

Want to do a simple login? HAHAHA GOOD LUCK! Here's 47 different configuration options you need to set up, three different flow types that are basically the same thing with slightly different names, and error messages that might as well be written in hieroglyphics. "AADSTS700054" yeah that's SUPER helpful, thanks Microsoft! And don't even get me started on token caching. Oh, you thought your tokens would just... work? NOPE! Hope you enjoy debugging why your perfectly valid token is being treated like a expired coupon at a grocery store. The refresh token flow is about as reliable as a chocolate teapot. I worked on a great project that was later axed and part of that was because of Msal issues. We literally only dealt with Msal issues. The app was otherwise stable. There were always issues with SSO, login, token validation... It just couldn't work, like, at all. I could see the clients getting fed up of the constant issues, yet, they couldn't move away from Microsoft since they'd already invested into their entreprise ecosystem. AzureAD, Office 365, you name it.