Why You should be Using Microsoft Azure Active Directory (AAD) Right Now

This document is relevant to both Azure Active Directory B2C and Active Directory Federated Services (ADFS), as both of these Microsoft offerings provide authentication/authorization services to cloud applications.

Not Reinventing the Wheel

Whenever news breaks of security breaches, an examination of the underlying cause points to implementations that either utilized a flawed code library or were a reinvention of existing standards. I have always been of the opinion that reinventing the wheel is how a better wheel gets invented; but where security is concerned, going with the latest peer-reviewed systems is the way to go.

You are Paying for it Anyway

Office 365

If your organization is using Office 365, your organization is already an Azure Active Directory tenant. Single-sign-on (SSO) capability and re-use of existing Identity as a Service (IDaaS) infrastructure can be extended to your enterprise applications in the cloud.

Microsoft Azure

If your Azure-hosted cloud applications manage user identities internally, you are already paying for the weight of that subsystem; by delegating that functionality to Azure AD, your identity management costs will be separate from the rest of your cloud applications' operational costs.

Other Hosting Providers

Every hosting provider has costs associated with bandwidth-heavy subsystems; delegating that functionality to Azure AD can lighten that load, perhaps costing less, in the long run.

Windows Server Active Directory

If your enterprise already has on-premise WSAD infrastructure, extending it to the cloud (through ADFS) is possible. The power to instantly block users is preserved, along with the added security of password hashes never being stored in the cloud. Additionally, multi-factor authentication becomes an option.

Things go Wrong

"If anything can go wrong, it will go wrong"

Cryptographic algorithms (such as SSL) are secured by the mathematical difficulty of reversing pseudo-irreversible calculations. If and when that mathematical difficulty is ever made trivial (by method or device), the resulting security breach will be almost universal.

When a security breach occurs, and you have implemented user identity management internally, your enterprise's name will be associated with the consequences of that breach; your development team will be tasked with fixing the breach as soon as possible; your competitors will be poised to acquire your now-unhappy customers.

If you delegate user identity management to Azure AD, Microsoft becomes the organization associated with the breach; Microsoft's development team is tasked with fixing the breach; and your application's unique functionality will not need to be altered in order to support the fix; in a worst-case scenario, only the aspects of an application that accept authentication/authorization information (such as tokens) would need to be altered.

Things go Right

"If life gives you lemons, make lemonade"

What do you do if you don't get lemons? Millions of sign-ups. High customer retention. Low customer attrition.

Large amounts of success can be disastrous if your user identity subsystem is not flexible enough to handle a high adoption rate; Azure AD is already designed to scale, as needed, to support your applications' success.

Everything Changes

Priorities change. Policies change. Applications change. But the user identity management systems should remain unchanged as much as possible, in order to remain compatible with the latest standards and best practices surrounding user identities. Using Azure AD means you can focus instead on your application's unique functionality, leaving the standard aspect up to Microsoft.

Staying Lightweight

Offloading infrastructural headaches, such as login problems, password resets, and out-of-band authentication, can keep your enterprise agile and lightweight; these become part of the work that the Azure AD team performs on behalf of your enterprise.

Staying Heavyweight

If your enterprise is (by necessity) locked-down and strictly on-premise, internal use of ADFS (to expose WSAD to your internal applications) allows you to develop those applications to use the standard interfaces (such as OAuth 2.0) that are already familiar in the cloud. This makes it possible to use existing code libraries/plugins that will both streamline development and make your internal applications function in a more familiar manner, and potentially cloud migrate-able.