EXPLAINER

Microsoft Entra ID

Microsoft Entra ID is Microsoft's cloud identity service, formerly Azure Active Directory. It signs users in, issues tokens, and holds the app registrations that Microsoft Graph, Azure and your own apps trust.

Short answer: Entra ID (formerly Azure AD) is the identity directory behind Microsoft 365 and much of Azure. Apps register there, users sign in, and tokens carry OAuth scopes. It is not the same thing as Windows Active Directory on a private network, though the two can sync.

What it is

Microsoft Entra ID is Microsoft's cloud directory and token service. The short name people use is Entra. The previous name, still everywhere in screens and libraries, is Azure Active Directory or Azure AD (AAD). A tenant holds users, groups and app registrations. When someone signs in to Microsoft 365, Azure, or your app, Entra ID is usually the system that checks the password or the authenticator and issues tokens.

It is not "Active Directory" in the old sense of domain controllers on a company LAN, although Entra Connect can synchronise those on-premises accounts into the cloud directory. It is also not an authorisation engine for every row in your database. Entra tells you who the caller is and which scopes or roles were granted. Your app still decides what that identity may do to your data.

Why and when it is used

Use Entra ID when users already have work accounts, when you call Microsoft Graph, or when you want conditional access (device compliance, MFA) applied to your app without building it yourself. App registrations are how a daemon, a web app or a single-page app gets a client id and, for confidential clients, a credential.

Use a different identity provider if your product's users are consumers with no Microsoft work account and you do not want to require one. You can still federate. Do not build a private password database for employees who already exist in Entra. That creates a second set of credentials security cannot revoke in one place.

How it works

An application registration defines the client id, redirect URIs, and the API permissions or exposed scopes. An enterprise application (a service principal) is that app inside a specific tenant, which is what admins consent to. Users authenticate with OpenID Connect; APIs are called with OAuth 2.0 access tokens, usually JWTs. Delegated permissions need a user. Application permissions need admin consent and have no user.

Conditional access policies sit in front of sign-in: they can require MFA, a compliant device, or a named location. Guest users are identities from other tenants invited into yours. Groups from Entra are the right way to assign people to an app role, rather than hard-coding email addresses.

Technologies and dependencies

Libraries: Microsoft Authentication Library (MSAL) for JavaScript, .NET, Python and Java. Protocols: OIDC for login, OAuth 2.0 for access tokens, Graph for directory queries if you must list users. Key material should be a certificate for production confidential clients. Client secrets work for learning and leak more easily. Redirect URIs must match exactly, including the port on localhost.

Your API, if you have one, should be registered as an exposed API with scopes (access_as_user) so tokens for your API are not confused with tokens for Graph. Validate issuer, audience and expiry. Do not accept any JWT a browser sends you.

How to get started

  1. In the Entra admin center, open App registrations and create a registration. Record the application (client) id and directory (tenant) id.
  2. Add a redirect URI for your local app.
  3. Add a client secret only if this is a confidential server app. Prefer a certificate when you leave the lab.
  4. Under API permissions add User.Read (Graph) and grant admin consent if you are the admin of a dev tenant.
  5. Use MSAL's auth-code sample for your language. Sign in. Decode the access token (audience and scopes) in a debugger, not in production logs.
  6. Call Graph /me. Then, separately, protect one route of your own API and require a token whose audience is your API.

Name the app after the product and the environment (contoso-invoices-dev). A tenant full of "test-app-final2" registrations is how secrets get forgotten.

Cautions and trade-offs

Secrets in git are a common Entra incident. Rotate them and use a store meant for secrets. Multi-tenant apps (any Microsoft work account) are a product decision: you must handle consent, tenant id on every row, and admin revocation. Single-tenant apps are safer for internal tools.

Azure AD and Entra ID are the same control plane under two labels. Docs and field names (aad) will not all say Entra. Do not create a second directory "to be safe" without knowing which tenant holds the users. Conditional access can break a daemon that has no user to satisfy MFA; service principals need the right exclusions or they will fail at 2 a.m. Finally, group membership in the token can be incomplete when groups are numerous; look up membership in Graph if your authorisation depends on it, and cache carefully.