Exchange Online Identity Models & Authentication Demystified (Part 5)

If you would like to read the other parts in this article series please go to:

• Exchange Online Identity Models and Authentication Demystified (Part 1)
• Exchange Online Identity Models and Authentication Demystified (Part 2)
• Exchange Online Identity Models and Authentication Demystified (Part 3)
• Exchange Online Identity Models and Authentication Demystified (Part 4)
• Exchange Online Identity Models and Authentication Demystified (Part 6)
• Exchange Online Identity Models and Authentication Demystified (Part 7)

Introduction

In part 4 of this article series revolving around the available identity models and the authentication story for Exchange Online, our focus was on the Exchange Online authentication story as it was in the past up until now. We talked about the two major pain points seen from the end user/client perspective.

Let’s get going.

Modern Authentication, ADAL and OAuth – What is it?

Over the last couple of years, the respective teams at Microsoft have worked on moving their cloud services (including the Office 365 workloads) to an OAuth based authentication model. For those that are not familiar with OAuth, let me give you a short explanation. OAuth (Open Authentication) is an open authorization standard that was born back in November 2006, so it is by no means a new standard. OAuth is used by most of the largest and popular service providers both in the consumer and enterprise space nowadays. More specifically service providers like Amazon, Facebook, LinkedIn, Google, Instagram, Foursquare, Twitter, DropBox and PayPal use OAuth and most of them have done so for many years. Actually, several of them used OAuth based authentication from the day they were born. Yammer which was acquired by Microsoft also used OAuth based authentication and still does this today.

As you can see OAuth is the authorization standard when it comes to cloud services and it was therefore a natural move for Microsoft to start moving their cloud services to this standard as well. And so they did and as of today most of the Microsoft cloud services including the browser based Office 365 workloads use OAuth today. Even things like Exchange hybrid configurations and Exchange Web Services (EWS) can utilize OAuth today.

Since OAuth is an authentication model mostly used for web based clients and services, Microsoft had to come up with a plan for utilizing this standard for rich/active clients like the Outlook Desktop client so they could fulfill the goal of ending up with a single authentication model used by all Office 365 clients and services irrespective of the devices used.

The Azure Active Directory team at Microsoft created the so called Azure AD Authentication Library (ADAL) that assists developers in enabling client application to authenticate users to Azure Active Directory (AAD) or on-premises Active Directory (AD) using OAuth based authentication.

When it comes to Office applications accessing Office 365 workloads, the Modern Authentication team naturally decided to use ADAL to facilitate sign in with Azure AD for Office client applications going forward. ADAL replaces the Microsoft Online Sign-in Assistant (SIA), that we talked about in the previous article, and when it comes to supported Office versions, Office 2013 and later is supported. For Office 2016, ADAL is included with the RTM build and for Office 2013, it is included in March 2015. Office 2013 also requires you to enable a registry key to be set in order to facilitate ADAL based authentication. Also, for the Exchange Online workload, you must ensure the tenant has OAuth based authentication support enabled (more on this in the next article).

By enabling ADAL for Office client applications, they will use an in-application browser control to render the Azure AD sign in experience in the same fashion as browser-based Office 365 clients like the Outlook on the Web (OotW). ADAL based OAuth authentication works for federated as well as non-federated scenarios.

With ADAL enabled in the Office client, we no longer rely on using basic authentication for the Outlook client and because of this, we also no longer need to store the credentials of the user on the client device, which is a huge step forward that eliminates one of the major pain points we talked about in the previous article. It also means that Exchange Online no longer needs to send the authentication credentials to Azure AD using proxy authentication (proxy auth) as we now use the WS-Fed passive profiles instead of the WS-Trust Active Profiles.

Modern Authentication (OAuth) Client Tokens Explained

When we enable ADAL for an Office client (aka modern authentication), we use OAuth based authentication as I also mentioned earlier. OAuth uses access and refresh tokens to allow access to Office 365 workloads using Azure Active Directory. In the OAuth world, two tokens are provided to the client when it has authenticated successfully against Azure AD. An access token is a JSON Web Token (JWT) which is valid for 1 hour and a refresh token which is valid for 14 days. If the tokens are active, which they will be if Office 365 workloads are accessed frequently, which usually is the case (especially for the Outlook desktop client), the refresh token can be valid for up to 90 days. So with frequent use of Office 365 workloads, the end user would only need to authenticate every third month as the access token will be kept alive by the refresh token. However, bear in mind the refresh token on the client can be invalidated. There are a few things that can invalidate a refresh token, the most common being the end user password being changed after the refresh token has been issued.

The same access and refresh tokens are used for federated and non-federated scenarios and should not be confused with SAML tokens, which are the ones end users are provided with from the identity provider (AD FS). And bear in mind, the life time values for access and refresh tokens cannot be changed. You do have more options at your disposal for federated scenarios though as you can leverage the features in AD FS 3.0.

If an end user does not have valid tokens on the client, he will be prompted for credentials as shown in Figure 1.

Figure 1: ADAL enabled Outlook Client prompted for credentials

The above login page is from the AD FS servers in a federated identities model. If you have a non-federated identity model, you will see the login page from Azure AD.

For general information around session timeouts for Office 365 clients other than ADAL enabled clients, see this piece of documentation on the Office 365 Support site.

Exchange Authentication Flow for Modern Authentication Clients

In a Federated Identities model where AD FS is used for federation and where ADAL is enabled on the Office client, the authentication flow will, as already mentioned, be identical to the flow for browser-based clients in a federated identities model as depicted in Figure 2.

Figure 2: Authentication Flow for ADAL enabled Outlook Client

However, the involved components and mechanisms differ a little, so let me explain what happens under the hood. The Outlook desktop client is launched and will try to connect to “outlook.office365.com”. Exchange Online redirects the ADAL enabled Outlook client to the authentication endpoint in Azure Active Directory (login.microsoftonline.com). The Outlook client will use the ADAL browser control to reach out to Azure Active Directory. The Azure AD authentication endpoint will detect the UPN domain is federated and do another redirection to the internal AD FS endpoint on-premises (in my case “fs.azurelab.dk”), where AD FS will require the client to authenticate.

Once authenticated, AD FS will retrieve the necessary claims related information from Active Directory and provide the ADAL enabled Outlook client with a SAML token holding the claims about the user. The client will present the token to Azure AD and after successful authentication, the client will be provided with a JWT token, that the Outlook client can use with Exchange Online on behalf of the user. The major benefit here is that the Outlook client, unlike when basic authentication is used, never handles the user’s credentials as such.

For domain-joined clients located on the internal network, you should rarely see a prompt for credentials, when you open an ADAL enabled Outlook client. For external ADAL enabled Outlook clients, it depends on how frequently the end user access Exchange Online as explained in the “Modern Authentication (OAuth) Client Tokens Explained“ section.

So as you can see, we now have a single authentication flow for all clients accessing Office 365 workloads and unlike when basic authentication is used, the authentication will be more transparent to end the user as it does not involve using the credentials manager to store credentials on the client.

This concludes part 5 of this multi-part article in which I provide you with an insight into the new Modern Authentication story and how it affects clients connecting to Exchange Online.

If you would like to read the other parts in this article series please go to:

• Exchange Online Identity Models and Authentication Demystified (Part 1)
• Exchange Online Identity Models and Authentication Demystified (Part 2)
• Exchange Online Identity Models and Authentication Demystified (Part 3)
• Exchange Online Identity Models and Authentication Demystified (Part 4)
• Exchange Online Identity Models and Authentication Demystified (Part 6)
• Exchange Online Identity Models and Authentication Demystified (Part 7)