When I started to develop my first small applications, I usually wasn’t concerned too much about security and about how to keep user data safe from exposure. But the deeper I digged into developing apps, the more I figured out how hard it was to design a truly secure way to store sensitive personal data. So I looked for third-party software that could solve this problem for me.
If you’re searching for identity management providers, one of the first platforms you will find is Active Directory (AD), a tool developed by Microsoft that was first launched in 1999 and since then evolved to the leading Identity and Access Management (IAM) software for enterprises. But although this makes Active Directory a very important skill to cover for software engineers, it also means that the software has to cover a lot of different use cases, making it seem very complex at the start. Therefore I hope to make your start with Active Directory a joy by sharing a walk-through tutorial of the login flow (written in Node.js) and by explaining the underlying concepts of Active directory in the process.
TL;DR: Is this tutorial suitable for me? Ask yourself these questions:
- Do I want to understand how an IAM software works?
- Do I want to explore different Azure Active Directory versions and how they differ?
- Do I want to build a login mechanism with Azure Active Directory?
- Do I want to learn more about OAuth2?
- Do I want to learn how to secure my users sensitive data?
If you can answer any of those questions with “Yes”, this is your tutorial. We will cover the following topics:
- What and why is Active Directory
- The developers opportunity
- Active Directory for everyone with AAD B2C
- OAuth2 in a nutshell
- Where to learn more
This tutorial is seperated in two articles: A theoretical introduction to Azure Active Directory (You are here) and a hands-on walk-through. You can find an implementation of how to log your user in with Azure Active Directory in this GitHub repository.
What and why is Active Directory
So before we start working with Active Directory we should understand what exactly AD actually is. Basically, AD stores all kind of entity information in an organization. That could be for example data about users, groups, devices, organizations or permissions between those entities. So it is far more than just a pure user management platform, although in this tutorial we will only focus on the user management features.
Historically, Active Directory was an On-Premise solution, meaning that every company using this technology had it installed in their own datacenters, completely isolated from all other Active Directories out there. After some time solutions were provided to connect two specific Active Directory tenants with each other, so that the employees from Company A could for example get access to devices of Company B and vice versa.
With the rise of cloud and Microsoft Azure specifically a new form of AD was provided: Azure Active Directory. Here, all Active Directories are connected with each other, meaning that someone from Company A could for example access an application developed internally at Company B if Company B allows that option in their application (more on how to handle that in the Coding section). This eliminates a lot of configuration overhead and makes it far easier to develop B2B applications as the app developed in your AD tenant can now be accessed by either individual users of another company or can register in the AD tenant of your customer (if you’re interested in that, you can dig deeper into AD scopes and delegated vs app permissions).
Active Directory tenants that are hosted on-premise, meaning not in Azure, are not accessible by Azure by default but can also connect to the Azure Active Directory via Azure AD Connect to replicate their user data to Azure Active Directory.
The developers opportunity
Coming from its long history and its deep integration with the Microsoft ecosystem, Active Directory was the de-facto standard for identity management in companies. And even though on-premise identity management isn't on its prime anymore, a lot of companies stayed with what they know and migrated directly to Azure Active Directory. There are also a lot of reasons to do so even nowadays: Office 365, Dynamics 365 and Azure (the "three clouds" of Microsoft) all work with Azure Active Directory. So whenever you want to use the cloud-hosted Office, you will need an Azure Active Directory account. Also every user with a Microsoft account (for example someone who uses Outlook or has a XBOX account) is also using Azure Active Directory under the hood.
This makes AAD a huge deal for developers. Especially if you develop an application for the enterprise sector, you often have to argue over how to access data and store user information. By integrating your application in Azure Active Directory, you don't have to store any personal user data (e.g. names), your users have a seamless single-sign-on experience and your customers admins still have control over which users and which data your app can reach out to. This spares you a lot of user management development efforts and makes user adoption a lot easier.
Active Directory for everyone with AAD B2C
Active Directory in the first place was a B2B product, designed for companies to handle their internal resources. As more and more companies developed complex B2C apps a new branch of Active Directory was released: Azure Active Directory B2C. While this version was downsized in terms of micro-management of users as well as in its capability to handle resources like devices, rooms and organizations, it came with a lot more features to handle a massive, anonymous amount of users, like self-registration into the active directory via e.g. Facebook, Google, Mail or LinkedIn and advanced features to store custom user metadata.
Furthermore a new version of the Active Directory login API was released, making it possible to authenticate personal Microsoft Accounts (e.g. outlook or msn email-adresses) into Active Directory applications. Therefore there currently are two options to develop B2C apps with Active Directory: You could use the traditional Azure Active Directory and allow users to log in from any domain (including the public Microsoft Active Directory that holds all @live.com, @outlook.com,... users). Or you use Azure Active Directory B2C to build your own Active Directory instance which holds all the users of you app. This approach holds a lot more benefits like expanding AD with custom metadata, and making it possible for people without a Microsoft account to use your app.
OAuth2 in a nutshell
Now that we know a lot more about the "What" of Active Directory, we want to look into the "How". Specifically, how can we authenticate into Azure Active Directory (AAD).
AAD uses the OpenID Connect specification to handle the sign-in process of its users. OpenID Connect is an extension to OAuth 2.0, which was built to standardize identity verification throughout all systems. OAuth 2.0 only specifies the Authorization of users, meaning: How can one user proof that he is allowed to do what he wants to do? Although this is a crucial step in securing Web Apps from malicious access, it still doesn't answer the question: Who is that person that wants to access my app? Therefore, OpenID Connect was written and took care of the Authentication of users. As OpenID Connect (also called OIDC in short) builds on OAuth2.0, every system that implements OIDC always also implements OAuth2.0.
The good thing is: We don't have to implement the Authentication part on ourselves when we start with AAD. Although it is a good idea to think about Authentication more deeply in production apps, the core logic of signing users in and looking up who they are is handled by Azure Active Directory for us. We only have to care about Authorization of our users, so getting to do something with their data.
OAuth2.0 offers a variety of possibilities to authorize your users. The most intuitive one (and the most common for Web Apps) is the authorization code flow. This flow has two steps: In step 1, you redirect your user to a Microsoft hosted login page, where users can log in with their username/e-mail and password. When the login was successful, we enter step 2: Azure Active Directory sends an authorization code to your application. You now have a proof that your user is signed in, and you can trade this authorization code for a so-called JSON Web Token (JWT). And that JWT can be then used to query services like the Microsoft Graph or Azure Active Directory to receive and manipulate data on behalf of the user that signed in.
Where to learn more?
If you want to go into the technical how of this concept, you can check out this article that walks you through an implementation of the authorization code flow.
If you already have an existing AAD integration, there is another exiting offer you can use. Microsoft offers a dedicated store just for AAD integrated apps where you can promote your app completely free of charge. To get started, take a look at the official documentation.
Top comments (1)
This was very insightful, thanks!