Inconvenient Internet Explorer security zones and Azure AD web applications
When building Azure AD web applications you have to ensure that they are in the same security zone as other Office 365 resources.
Is it broken?
Have you ever found yourself in a situation where you would build a web application registered with Azure AD and you couldn’t get past the authentication flow? Depending on your application you would either end up in an infinite loop between your application and Azure AD login page or you would login in Azure AD but your application would still present you the login page. Sounds familiar?
Even though everything seems to be just fine with your code and Fiddler doesn’t show any errors, your application isn’t working as expected and eventually it might take you a while to figure out why this is happening. The odd part is that this is only happening in Internet Explorer which, inconveniently enough, is the browser that everyone in your organization is using.
Inconvenient Internet Explorer security zones and Azure AD web applications
Internet Explorer uses security zones to allow web-based resources access the different resources on your computer. Depending on the zone in which the particular web application is configured it will be allowed to perform certain actions and denied to do others. What’s truly important however is the fact how Internet Explorer deals with cookies and the different security zones.
The odds are high that if you are working with Office 365 and have Office client applications installed on your computer, your Office 365 tenant and the Office 365 login page are in the Trusted sites security zone. In the list of trusted sites you would see URLs such as https://yourtenant.sharepoint.com, https://yourtenant-my.sharepoint.com and https://login.microsoftonline.com. While this works just as expected, problems arise when you build a custom web application registered with Azure AD and will try to authenticate using your Office 365 account in that application.
By default all web applications run in the Internet security zone. Although the default settings of that zone are irrelevant for this specific issue, what’s causing trouble is the fact that your web application is in a different security zone than your Office 365 tenant and the Azure AD login page. Because Internet Explorer doesn’t exchange cookies between the different security zones, even though you will complete the authentication flow against Azure AD, the authentication cookie will remain in the Trusted sites zone and your web application will still want you to authenticate with Azure AD. The solution to this issue is to add the URL of your web application to the Trusted sites zone in Internet Explorer – just next to your Office 365 tenant and the Azure AD login page.
It’s not only for standalone web applications
Standalone Azure AD web applications are not the only place where you will encounter the issue with Internet Explorer security zones. In fact the odds are high that you will notice this issue earlier, when trying to open an Office Add-in in one of your Office web applications.
Technically Office Add-ins work the same way as standalone Azure AD web applications and as such they have the same requirements. The additional complexity here is the particular Office web application in which you are opening the Office Add-in: just as the Office Add-in and your Office 365 tenant it should also be added to the Trusted sites zone. If you are using the Outlook Web App (OWA) for example you would add https://outlook.office365.com to the list of your Trusted sites in Internet Explorer to ensure that Outlook and your Outlook Add-ins work correctly.
Summary
Security zones are specific to Internet Explorer and other browsers don’t have similar restrictions. Given that many organizations use Internet Explorer the chances are that you will encounter some odd behavior when working with Azure AD web applications and Office Add-ins. Confirming that all the necessary URLs are listed in the Trusted site security zone in Internet Explorer should be your first step in debugging unexpected authentication issues which take place only in Internet Explorer.