The second part of John Craddock’s deep-dive series into Azure Active Directory discusses protocols, and the common ways to secure your website or web service.
In this series, I will take you through the key aspects of Azure Active Directory, and you will discover how using Azure AD you can build identity solutions for the future. The series is about the technology rather than the marketing hype. It’s also something I cover in more depth in my masterclass, which is a deep-dive into the technologies and goes into the real technical detail. For an introduction to this series and some background on myself, see Episode 1: Introductions all round.
Episode 2: It’s all about protocols
In today’s ecosystems with the adoption of the cloud we need to be able to authenticate to applications and services regardless of where those services reside, be they on-premises, in a public cloud or hosted by a partner. Typically these applications and services are accessed over HTTP/HTTPS and to simplify the terminology, in this article I will use “application” to refer to a website or web service.
The traditional approach to authentication has been for each application provider to host an identity store (directory) and for the user to sign-up for access. During the sign-up process, the user provides a username, password and any other profile information that may be required by the provider. The user authenticates to the application with the username and password held in the directory. The immediate challenge for the user is that they have to remember multiple passwords and sign in for access to each resource. In a corporate environment, which is adopting cloud services, the challenge for the system administrators is how to provision a user’s access to all of the different resources and disable access when the user leaves the company. In most cases, the administrators are not in control of the provisioning and de-provisioning processes. They must rely on the third-parties who own the identity stores. Consequently, there will be delays in provisioning access for the user, and orphaned accounts can exist long after a user has left an organisation.
To address this vexing problem, we need an identity framework that can be consumed by an application regardless of where it is hosted. The application may be hosted on-premises, in a public/private cloud, or by a partner organization. This solution needs to use industry standard protocols and provide single-sign-on access for the user to all the required applications. Federation identity provides the solution framework. Federation means trust, so we are talking about trusted identities. We could have a single identity store that authenticates the user and creates a signed token which is presented to the application as proof that the user is authenticated. Figure 1 shows the components at work. The entity that issues the token for the application is referred to as the Security Token Service (STS). The application trusts the token once it has validated the signature.
Traditionally the two leading protocols for federated identity have been SAML-P and WS-Federation. However, the need to support simpler mobile devices and applications spawned the development of new authentication protocols. After various iterations, the protocol standard for authentication is OpenID Connect and the protocol for delegating access from one application to another is OAuth 2.0. OpenID Connect layers on top of Auth 2.0. SAML-P and WS-Federation use a heavyweight XML SAML token, whereas a simpler JSON Web Token (JWT – pronounced JOT) is supported for the new protocols. You can see the token types contrasted in Figures 2 and 3.
Both OpenID Connect and OAuth 2.0 can support many different scenarios, and the actual protocol flow varies between the scenarios. Figure 4 illustrates the protocol flow when a user authenticates (using OpenID Connect) to an application and the application requests (using OAuth 2.0) an access_token to the Azure AD GraphAPI to read the user’s profile data. In OAuth2.0 terminology the application that wants to access the backend system is referred to as the client.
Running through the steps as shown in Figure 4: Hybrid flow.
- The user agent (UA aka browser) accesses the application. The application checks for a cookie that would indicate that the UA has previously authenticated.
- As there is no authentication cookie presented, the application redirects the UA to Azure AD for authentication.
- After authentication, Azure AD returns an id_token that is proof that the user has been authenticated to the application. In addition, a code is returned that can be converted to an access_token for access to the GraphAPI. A cookie is set to signify that the user has been authenticated to Azure AD.
- The code and id_token posted back to the application. The application validates the id_token and uses it as proof that the user has been authenticated.
- The application sends the code to Azure AD. Azure AD returns an access token for the GraphAPI.
- The access_token is used to authenticate to the GraphAPI using the identity of the user.
- The requested user profile data is returned to the application.
- The application renders the requested page back to the UA. A cookie is set to signify that the user has been authenticated to the application.
To emphasise the authentication service, the GraphAPIs and to show the flow, two Azure ADs are shown in Figure 4. In reality, there is only one Azure AD tenant involved in this scenario.
The steps highlight the key points, and for brevity, I have had to leave out details of user consent, and refresh tokens.
Please watch the video which shows authenticating to an OpenID Connect secured application and converting the code to an access_token. That’s it until next time.
For details of all the episodes in this series, look here. To learn and become skilled in implementing identity systems based on Azure AD, on-premises AD and AD FS join me at one of my Masterclasses. To find out more visit XTSeminars.