- name: Considerations and known issues

- name: MSAL.NET

items:

- name: Web browsers

href: msal-net-web-browsers.md

- name: Xamarin Android

href: msal-net-xamarin-android-considerations.md

- name: System browser on Android

href: msal-net-system-browser-android-considerations.md

- name: Xamarin iOS

href: msal-net-xamarin-ios-considerations.md

- name: Universal Windows Platform

href: msal-net-uwp-considerations.md

- name: Apply an AAD B2C policy

href: msal-net-aad-b2c-considerations.md

- name: MSAL.js

items:

- name: Considerations using IE

href: msal-js-use-ie-browser.md

- name: Known issues- IE and Microsoft Edge

href: msal-js-known-issues-ie-edge-browsers.md

- name: Known issues- Safari

href: msal-js-known-issues-safari-browser.md

title: Known issues on browsers (Microsoft Authentication Library for JavaScript) | Azure

description: Learn about know issues when using the Microsoft Authentication Library for JavaScript (MSAL.js) with Internet Explorer and Microsoft Edge browsers.

services: active-directory

documentationcenter: dev-center-name

author: navyasric

manager: CelesteDG

editor: ''

ms.service: active-directory

ms.subservice: develop

ms.devlang: na

ms.topic: troubleshooting

ms.tgt_pltfrm: na

ms.workload: identity

ms.date: 05/16/2019

ms.author: nacanuma

ms.reviewer: saeeda

ms.custom: aaddev

ms.collection: M365-identity-device-management

We had multiple reports of issues with authentication in IE and Microsoft Edge (since the update of the *Microsoft Edge browser version to 40.15063.0.0*). We are tracking these and have informed the Microsoft Edge team. While Microsoft Edge works on a resolution, here is a description of the frequently occurring issues and the possible workarounds that can be implemented.

The cause for most of these issues is as follows. The session storage and local storage are partitioned by security zones in the Microsoft Edge browser. In this particular version of Microsoft Edge, when the application is redirected across zones, the session storage and local storage are cleared. Specifically, the session storage is cleared in the regular browser navigation, and both the session and local storage are cleared in the InPrivate mode of the browser. MSAL.js saves certain state in the session storage and relies on checking this state during the authentication flows. When the session storage is cleared, this state is lost and hence results in broken experiences.

- **Infinite redirect loops and page reloads during authentication**. When users sign in to the application on Microsoft Edge, they are redirected back from the AAD login page and are stuck in an infinite redirect loop resulting in repeated page reloads. This is usually accompanied by an `invalid_state` error in the session storage.

- **Infinite acquire token loops and AADSTS50058 error**. When an application running on Microsoft Edge tries to acquire a token for a resource, the application may get stuck in an infinite loop of the acquire token call along with the following error from AAD in your network trace:

`Error :login_required; Error description:AADSTS50058: A silent sign-in request was sent but no user is signed in. The cookies used to represent the user's session were not sent in the request to Azure AD. This can happen if the user is using Internet Explorer or Edge, and the web app sending the silent sign-in request is in different IE security zone than the Azure AD endpoint (login.microsoftonline.com)`

- **Popup window doesn't close or is stuck when using login through Popup to authenticate**. When authenticating through popup window in Microsoft Edge or IE(InPrivate), after entering credentials and signing in, if multiple domains across security zones are involved in the navigation, the popup window doesn't close because MSAL.js loses the handle to the popup window.

Here are links to these issues in the Microsoft Edge issue tracker:

- [Bug 13861050](https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/13861050/)

- [Bug 13861663](https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/13861663/)

Fixes for the authentication redirect loop issues have been released in [MSAL.js 0.2.3](https://github.com/AzureAD/microsoft-authentication-library-for-js/releases). Enable the flag `storeAuthStateInCookie` in the MSAL.js config to take advantage of this fix. By default this flag is set to false.

When the `storeAuthStateInCookie` flag is enabled, MSAL.js will use the browser cookies to store the request state required for validation of the auth flows.

Use workarounds below.

Make sure to test that your issue is occurring only on the specific version of Microsoft Edge browser and works on the other browsers before adopting these workarounds.

1. As a first step to get around these issues, ensure that the application domain, , and any other sites involved in the redirects of the authentication flow are added as trusted sites in the security settings of the browser, so that they belong to the same security zone.

To do so, follow these steps:

- Open **Internet Explorer** and click on the **settings** (gear icon) in the top-right corner

- Select **Internet Options**

- Select the **Security** tab

- Under the **Trusted Sites** option, click on the **sites** button and add the URLs in the dialog box that opens.

2. As mentioned before, since only the session storage is cleared during the regular navigation, you may configure MSAL.js to use the local storage instead. This can be set as the `cacheLocation` config parameter while initializing MSAL.

Note, this will not solve the issue for InPrivate browsing since both session and local storage are cleared.

There are cases when popups are blocked in IE or Microsoft Edge, for example when a second popup occurs during multi-factor authentication. You will get an alert in the browser to allow for the popup once or always. If you choose to allow, the browser opens the popup window automatically and returns a `null` handle for it. As a result, the library does not have a handle for the window and there is no way to close the popup window. The same issue does not happen in Chrome when it prompts you to allow popups because it does not automatically open a popup window.

As a **workaround**, developers will need to allow popups in IE and Microsoft Edge before they start using their app to avoid this issue.

Learn more about [Using MSAL.js in Internet Explorer](msal-js-use-ie-browser.md).

title: Known issues on browsers (Microsoft Authentication Library for JavaScript) | Azure

description: Learn about know issues when using the Microsoft Authentication Library for JavaScript (MSAL.js) with Safari browser.

services: active-directory

documentationcenter: dev-center-name

author: navyasric

manager: CelesteDG

editor: ''

ms.service: active-directory

ms.subservice: develop

ms.devlang: na

ms.topic: troubleshooting

ms.tgt_pltfrm: na

ms.workload: identity

ms.date: 05/16/2019

ms.author: nacanuma

ms.reviewer: saeeda

ms.custom: aaddev

ms.collection: M365-identity-device-management

Apple iOS 12 and MacOS 10.14 operating systems included a release of the [Safari 12 browser](https://developer.apple.com/safari/whats-new/). For purposes of security and privacy, Safari 12 includes the [Intelligent Tracking Prevention 2.0](https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/). This essentially causes the browser to drop third-party cookies being set. ITP 2.0 also treats the cookies set by identity providers as third-party cookies.

MSAL.js uses a hidden Iframe to perform silent token acquisition and renewal as part of the `acquireTokenSilent` calls. The silent token requests rely on the Iframe having access to the authenticated user session represented by the cookies set by Azure AD. With ITP 2.0 preventing access to these cookies, MSAL.js fails to silently acquire and renew tokens and this results in `acquireTokenSilent` failures.

There is no solution for this issue at this point and we are evaluating options with the standards community.

By default the ITP setting is enabled on Safari browser. You can disable this setting by navigating to

**Preferences** -> **Privacy** and unchecking the **Prevent cross-site tracking** option.


You will need to handle the `acquireTokenSilent` failures with an interactive acquire token call, which prompts the user to sign in.

To avoid repeated sign-ins, an approach you can implement is to handle the `acquireTokenSilent` failure and provide the user an option to disable the ITP setting in Safari before proceeding with the interactive call. Once the setting is disabled, subsequent silent token renewals should succeed.

title: Use Internet Explorer (Microsoft Authentication Library for JavaScript) | Azure

description: Learn about using the Microsoft Authentication Library for JavaScript (MSAL.js) with Internet Explorer browser.

services: active-directory

documentationcenter: dev-center-name

author: navyasric

manager: CelesteDG

editor: ''

ms.service: active-directory

ms.subservice: develop

ms.devlang: na

ms.topic: conceptual

ms.tgt_pltfrm: na

ms.workload: identity

ms.date: 05/16/2019

ms.author: nacanuma

ms.reviewer: saeeda

ms.custom: aaddev

ms.collection: M365-identity-device-management

Microsoft Authentication Library for JavaScript (MSAL.js) is generated for [JavaScript ES5](https://fr.wikipedia.org/wiki/ECMAScript#ECMAScript_Edition_5_.28ES5.29) so that it can run in Internet Explorer. There are, however, a few things to know.

If you intend to use MSAL.js in applications that can run in Internet Explorer, you will need to add a reference to a promise polyfill before referencing the MSAL.js script.

<script src="https://cdnjs.cloudflare.com/ajax/libs/bluebird/3.3.4/bluebird.min.js" class="pre"></script>

This is because Internet Explorer does not support JavaScript promises natively.

Deploying your application to production (for instance in Azure Web apps) normally works fine, provided the end user has accepted popups. We tested it with Internet Explorer 11.

If you want to run and debug locally your application running in Internet Explorer, you need to be aware of the following considerations (assume that you want to run your application as *http://localhost:1234*):

- Internet Explorer has a security mechanism named "protected mode", which prevents MSAL.js from working correctly. Among the symptoms, after you sign in, the page can be redirected to http://localhost:1234/null.

- To run and debug your application locally, you'll need to disable this "protected mode". For this:

1. Click Internet Explorer **Tools** (the gear icon).

1. Select **Internet Options** and then the **Security** tab.

1. Click on the **Internet** zone, and uncheck **Enable Protected Mode (requires restarting Internet Explorer)**. Internet Explorer warns that your computer is no longer protected. Click **OK**.

1. Restart Internet Explorer.

1. Run and debug your application.

When you are done, restore the Internet Explorer security settings. Select **Settings** -> **Internet Options** -> **Security** -> **Reset all zones to default level**.

Learn more about [Known issues when using MSAL.js in Internet Explorer](msal-js-use-ie-browser.md).