Most access problems in Azure trace back to one confusion, and Microsoft Entra ID sits at the center of it. An engineer assigns someone the Global Administrator role and is baffled when that person still gets a 403 trying to read a storage blob. A developer registers an application, gets a token, and cannot understand why the API keeps rejecting it. A team treats their cloud directory like the on-premises Active Directory they have run for a decade, then discovers that none of the muscle memory transfers. Each of these is the same mistake wearing a different costume: treating identity and resource access as one thing when Azure splits them into two distinct planes. This guide builds the mental model that dissolves the confusion, so you can reason about how an application obtains a token and what a role assignment actually grants instead of guessing.

The product carried the name Azure Active Directory for years, and Microsoft renamed it to Microsoft Entra ID in 2023. The older name appears throughout existing documentation, blog posts, portal screenshots, and the error codes you will still hit, so it helps to acknowledge it once: Azure AD and Entra ID are the same identity service. From here on this guide uses Entra ID, because the name itself encodes the most important lesson. It is not a cloud-hosted copy of Active Directory. It is an identity and access management platform built for the cloud, for web and mobile applications, and for the protocols those applications speak. Understanding why the rename matters is the first step toward understanding the service.

What Microsoft Entra ID actually is

Microsoft Entra ID is a multi-tenant, cloud-based identity and access management service. Strip that phrase down and three ideas carry the weight. It is multi-tenant, meaning every organization gets its own isolated directory instance. It is an identity service, meaning its job is to answer the question of who or what is making a request and to issue a verifiable proof of that identity. And it is an access management service, meaning it also governs which applications a given identity is allowed to call and under what conditions.

The mental model to hold is a hotel rather than a building’s keyring. In an old-fashioned office building, the facilities manager keeps a ring of physical keys, and a key opens a door because the key’s cut matches the lock’s pins. Possession is everything, and the lock has no idea who is holding the key. Active Directory’s domain model leans on something close to this: a domain-joined machine and a Kerberos ticket grant access inside a trusted network boundary, and a great deal of the security comes from the network perimeter itself. Entra ID works like a modern hotel with a front desk. You prove who you are at check-in, the desk issues you a credential scoped to specific doors for a specific window of time, and every door reads that credential and decides for itself whether to open. The credential is a token. The front desk is the Entra ID token issuer. The doors are applications and APIs. Nothing trusts the network; everything trusts the token and verifies it on the spot.

This shift from network trust to token trust is the conceptual core. In a perimeter model, being inside the network is most of the battle. In the identity model Entra ID implements, location buys you nothing on its own. An identity authenticates, a policy layer evaluates the conditions of that sign-in, and a token is issued that carries claims about who the identity is and what it is allowed to do. Every protected resource validates that token cryptographically and reads its claims. The network may still be one input into the decision, but it is an input, not the decision.

Why is Entra ID not just cloud Active Directory?

Entra ID does not use Kerberos or LDAP as its primary protocols, has no concept of organizational units or group policy, and does not act as a domain controller. It speaks OAuth 2.0 and OpenID Connect, the protocols of web and mobile applications. Active Directory Domain Services manages domain-joined Windows machines on a trusted network; Entra ID manages identities for cloud and SaaS applications across the open internet.

That distinction has teeth in practice. If you have an application that needs to authenticate users with Kerberos, join machines to a domain, or apply group policy objects, Entra ID alone does not do those things, and Microsoft offers a separate managed service, Entra Domain Services, for the specific case of running legacy directory-aware workloads in the cloud. The everyday Entra ID that fronts Microsoft 365, secures your Azure subscriptions, and issues tokens to your web apps is a different animal from the directory most administrators learned on. Confusing the two leads to a long string of wrong expectations, and the rename to Entra ID was in part an attempt to break the association before it caused another decade of misunderstanding.

The service also does jobs that have no Active Directory equivalent at all. It is the identity provider behind single sign-on to thousands of SaaS applications. It manages the consent framework that lets a third-party application request limited access to your data. It evaluates risk signals on every sign-in and can demand multifactor authentication when something looks off. It issues short-lived tokens to workloads so they can call Azure APIs without a stored password anywhere. None of that maps cleanly onto the on-premises directory model, which is exactly why importing that model wholesale leads engineers astray.

The tenant: the boundary that contains everything

Every Entra ID story begins with a tenant. A tenant is a dedicated and isolated instance of the directory that an organization owns. When a company signs up for Microsoft 365 or creates an Azure subscription, a tenant is created for it, and that tenant becomes the container for all of the organization’s identities, application registrations, groups, and policies. The tenant is the trust boundary. An identity defined in one tenant is not automatically known or trusted in another; crossing that line requires explicit configuration such as guest invitations or multi-tenant application consent.

A tenant is identified by a globally unique tenant ID, a GUID, and usually by one or more domain names. Every new tenant gets a default domain of the form yourcompany.onmicrosoft.com, and organizations typically add their own verified custom domains, such as yourcompany.com, on top of it. When you authenticate, you authenticate against a specific tenant, and the authority you use in a token request names that tenant. This is why the same user account cannot simply roam between organizations: the account lives inside one tenant’s boundary, and the token issued for it is stamped with that tenant’s ID.

What is the relationship between a tenant and an Azure subscription?

A tenant holds identities; a subscription holds resources and billing. One tenant can trust many subscriptions, and a subscription’s resources are secured by identities from exactly one tenant at a time. Authenticating proves who you are within the tenant; the subscription then decides, through Azure role assignments, what those resources let you do.

This separation trips up newcomers constantly. People assume that because they administer the Azure subscription, they administer the directory, or the reverse. In reality the two are governed by different role systems entirely, a point this guide returns to because it is the single most consequential thing to understand. The tenant is the identity authority. A subscription is associated with a tenant for authentication purposes, but managing the subscription’s resources and managing the tenant’s directory are separate responsibilities with separate roles. A person can be an owner of every subscription and hold no directory administration rights at all, and a person can be a directory administrator with no access to a single virtual machine.

Tenants also come in flavors that matter for how applications behave. A workforce tenant is the standard organizational directory for employees. An external tenant, formerly delivered through Azure AD B2C and now part of the broader external identities story, is built for customer-facing applications where the people signing in are consumers rather than employees. The behavior of identities, the available authentication methods, and the customization options differ between these, so when you read documentation it is worth confirming which tenant type a feature applies to before assuming it covers your case.

Identities: who and what can authenticate

Inside a tenant, the things that can hold an identity and authenticate fall into a few clear categories, and knowing them precisely prevents a surprising amount of confusion later. There are users, there are groups, and there are the identities that represent applications and workloads rather than people. Getting the last category right is where most engineers stumble, because the human-centric intuition does not cover it.

A user is the familiar case: a person with credentials who signs in interactively. Users come in two main kinds inside a tenant. Member users are the organization’s own people, created in the tenant or synchronized into it from an on-premises directory. Guest users are external people invited into the tenant through Entra ID’s business-to-business collaboration, so a partner at another company can be granted access to specific resources without your organization having to create a full account for them. Guests authenticate against their home tenant and are then recognized as guests in yours, which is the multi-tenant trust boundary working as designed.

Groups collect identities so that access can be granted to many principals at once. A security group can be assigned roles and given access to applications and resources, and membership can be assigned manually or driven dynamically by rules over user attributes. Groups are the unit of scale for access management; granting a role to a group and managing membership is far more sustainable than assigning the same role to a hundred individuals one at a time.

What is a service principal and how does it differ from an app registration?

A service principal is the local identity an application has inside a tenant, the thing that can be granted roles and consented permissions. An app registration, the application object, is the global definition of the application. The registration is the blueprint; the service principal is the instance of that blueprint running in a specific tenant.

This pairing deserves careful attention because the two objects are easy to conflate and the distinction explains a whole class of access failures. When you register an application in your tenant, you create an application object, also called the app registration. That object is the global definition: it holds the application’s identity, its credentials, the permissions it requests, and the APIs it exposes. The moment the application is actually used in a tenant, a service principal is created in that tenant to represent it locally. The service principal is what holds the application’s role assignments and the permissions that have been consented to in that tenant. In your home tenant, registering the app creates both objects together. In a multi-tenant scenario, the application object lives only in the publisher’s tenant, and a separate service principal is provisioned in each consuming tenant that uses the app. If a multi-tenant application has never been consented into a given tenant, no service principal exists there, and authentication against that tenant fails because Entra ID cannot find the application locally, which is the root of more than one cryptic error code.

Managed identities are a special, friendlier kind of service principal. A managed identity is an identity that Azure creates and manages for a workload such as a virtual machine, an app service, or a function, with no secret or certificate for you to store or rotate. The platform handles the credential entirely. When code running under a managed identity needs a token to call an Azure API, it asks the local Azure identity endpoint and receives one, and the secret that backs that exchange never touches your code or configuration. Managed identities come as system-assigned, tied to the lifecycle of a single resource, or user-assigned, created as a standalone resource and attachable to many. They are the right default for any Azure-hosted workload that needs to authenticate to Azure services, because they remove the stored credential that is otherwise the most common thing to leak. The full reasoning behind choosing a managed identity over a classic service principal is worth its own treatment, and the comparison of when each fits is covered in depth elsewhere in this series.

The reason to be precise about all of this is that authorization in Azure is granted to these principals, and a request fails or succeeds based on which principal is actually making it. A function calling storage under its managed identity needs the role assignment on that identity, not on the developer who wrote the code. A daemon service authenticating with a client secret acts as its service principal, and that service principal needs the permissions, not the human who set it up. Tracing any access problem starts with naming the principal correctly.

App registrations: how an application gets an identity

An application that wants to use Entra ID for sign-in or to call a protected API must first be registered. The app registration is the application’s identity record, and it is where you declare everything Entra ID needs to know to issue and validate tokens on the application’s behalf. A registration carries a client ID, the public identifier that uniquely names the application within the directory. It carries credentials, either client secrets or, preferably, certificates, that the application uses to prove it is itself when it requests a token without a user present. It declares redirect URIs, the exact addresses Entra ID is allowed to send a user back to after an interactive sign-in. It lists the API permissions the application requests. And if the application is itself an API that other applications will call, the registration is where it exposes its own scopes and application roles.

Each of these fields maps to a real behavior, and getting one wrong produces a specific, recognizable failure. The redirect URI is matched exactly, character for character including the trailing slash and the platform type, when an interactive sign-in completes; a mismatch produces the AADSTS50011 error, one of the most searched authentication failures, and the fix is always to copy the exact URI from the error into the right platform entry rather than to chase consent or credentials. We cover the full diagnosis of a redirect URI mismatch and the exact-match rule behind it in its own troubleshooting article, because the trap is subtle and the searches for it are constant.

Credentials on a registration deserve a deliberate choice. A client secret is a string, simple to create and simple to leak, with an expiry you must track and rotate before it lapses. A certificate is stronger, harder to exfiltrate, and the better choice for any production confidential client. The strongest option is to avoid a stored credential entirely by using a managed identity or a federated credential, so there is nothing to rotate and nothing to leak. When a secret expires unnoticed, the application stops authenticating and you get an invalid-client failure that looks alarming but reduces to a lapsed credential, which is why tracking expiry is part of operating any registration that still relies on secrets.

Why does my application object differ from the enterprise application?

The application object, your app registration, is the global template that defines the app. The enterprise application is the service principal, the local instance in a tenant that actually holds consent and role assignments. You configure the app on the registration; you grant it access on the enterprise application. They are two views of one application at two scopes.

In the portal these appear as two separate blades, App registrations and Enterprise applications, and the names do not make the relationship obvious. The App registrations blade shows application objects your tenant owns, the definitions you author and control. The Enterprise applications blade shows service principals, including the local instances of applications published by other organizations that have been consented into your tenant. When you grant admin consent to a third-party SaaS application, you are not editing its registration, which lives in the publisher’s tenant; you are configuring the service principal that represents it locally. When your own application misbehaves with permissions, the question of whether the problem is in the registration or in the local consent state determines where you look. Holding the application-object-versus-service-principal distinction in mind turns these two blades from a source of confusion into a precise map, and the full registration model, including the manifest and exposed APIs, is laid out in its own deep dive in this series.

Tokens and the flows that issue them

The output of an Entra ID authentication is a token, and tokens are the heart of the whole system. There are three kinds, and using the wrong one for the wrong purpose causes a large share of the authentication problems engineers report. An ID token proves to a client application who the user is; it is identity, meant to be read by the application that requested the sign-in, and it is the OpenID Connect addition on top of OAuth. An access token authorizes a call to a protected API; it is consumed by that API, which validates it and reads its claims to decide whether the caller may proceed. A refresh token is a long-lived credential a client can present to obtain new access tokens silently when the short-lived ones expire, so the user does not have to sign in again every hour.

The single most important rule about tokens is that an ID token proves identity to the application while an access token authorizes an API call, so most token confusion is using the wrong token for the wrong purpose. Sending an ID token to an API that wants an access token, or treating an access token as proof of who the user is, produces rejections that look mysterious until you name which token belongs where. The authentication pipeline in full, from credential to issued tokens, is the subject of its own article, and it is the natural next read once this model is in place.

Tokens are issued through OAuth 2.0 grant flows, and which flow an application uses depends on what kind of application it is and whether a user is present. An interactive web application or single-page application uses the authorization code flow, now always with Proof Key for Code Exchange, where the user signs in, the application receives a short-lived code, and the code is exchanged for tokens. A daemon or backend service with no user signs in as itself using the client credentials flow, presenting its own secret or certificate to obtain an application token. A workload running in Azure uses its managed identity to obtain a token from the local identity endpoint with no credential in code at all. Each flow exists for a reason, and copying a flow from a sample without understanding why often means picking the wrong one. The differences between the OAuth grant flows and which to use are explained at protocol depth elsewhere in this series.

The InsightCrunch token-flow map

The findable artifact for this article is a map that places every common authentication on one grid: which principal is signing in, which flow it uses, what credential it presents, what token it ends up with, and what that token is good for. When an authentication problem lands on your desk, the first move is to locate it on this map, because most problems are simply the wrong cell.

Principal	Is a user present?	Flow used	Credential presented	Token obtained	What the token authorizes
Interactive web user	Yes	Authorization code with PKCE	User credentials at sign-in, app secret or certificate at code exchange	ID token plus access token plus refresh token	Identity to the app, and a delegated API call on the user’s behalf
Single-page app user	Yes	Authorization code with PKCE (public client, no secret)	User credentials at sign-in	ID token plus access token (refresh via rotation)	Identity to the SPA, and a delegated API call on the user’s behalf
Native or mobile app user	Yes	Authorization code with PKCE (public client)	User credentials at sign-in	ID token plus access token plus refresh token	Identity to the app, and a delegated API call on the user’s behalf
Daemon or backend service	No	Client credentials	Client secret or certificate	Access token only	An application-level API call as the service itself
Azure-hosted workload	No	Managed identity token request	None in code; platform-managed	Access token only	An application-level API call as the managed identity
Input-constrained device	Yes, but elsewhere	Device code	User authorizes on a second device	ID token plus access token plus refresh token	Identity and a delegated API call on the user’s behalf

Read across a row and an entire class of authentication makes sense at once. A daemon never receives an ID token, because there is no user whose identity an ID token would carry; if your backend service is somehow looking for one, that is the misunderstanding to fix. A single-page application is a public client and holds no secret, so any design that has it presenting a client secret from browser code is leaking that secret and should be reworked. A managed identity presents no credential your code can see, which is the whole point and the reason it is the safest option for Azure-hosted workloads. The map turns a vague sense that something is wrong with the tokens into a precise statement of which row you are in and which cell does not match.

Permissions and consent: delegated versus application

When an application calls an API such as Microsoft Graph, it needs permission, and Entra ID offers two fundamentally different kinds. The difference governs not only what the application can do but who must approve it, and conflating them is a frequent source of both over-permissioning and unexplained failures.

A delegated permission lets the application act on behalf of a signed-in user, and the effective access is the intersection of what the application has been granted and what the user is themselves allowed to do. If the application has delegated permission to read mail and the signed-in user can read only their own mailbox, the application reading on their behalf is bounded by that user’s own rights. Delegated permissions fit interactive applications where a person is present and the application should never exceed that person’s reach.

An application permission lets the application act as itself, with no user in the picture and no user-scoped ceiling on what it can touch. A daemon that needs to read every mailbox in the organization uses an application permission, because there is no single user whose rights would bound it. Application permissions are powerful precisely because they are not limited by a user’s scope, and that power is why they require admin consent: a privileged directory administrator must approve them before they take effect. Delegated permissions can in many cases be consented by the user themselves, depending on the permission and the tenant’s consent policy, while application permissions always require an administrator.

When does an application need admin consent?

Application permissions always require admin consent, because the application will act as itself with organization-wide reach and no user to bound it. Many delegated permissions can be granted by the user signing in, but high-privilege delegated permissions, and any permission in a tenant configured to restrict user consent, also require an administrator to approve.

The consent step is where a lot of real-world authentication grinds to a halt, and the failures are recognizable once you know the model. A daemon configured with delegated permissions instead of application permissions will work in testing, when a developer is signed in, and then fail in production when it runs unattended with no user to delegate from. An application requesting a permission that needs admin consent, in a tenant where no administrator has granted it, produces a consent-required error that developers often misread as a code bug. The fix is rarely in the code; it is in matching the permission type to whether a user is present and in securing the right consent. The sibling of this is the case where an administrator has restricted user consent entirely, so even an ordinary delegated permission now waits on an admin, which changes the onboarding experience for every new application in the tenant.

The two-plane identity rule: Entra roles versus Azure RBAC

Here is the distinction that resolves more confusion than any other in Azure, and it is the namable claim this article advances. Entra ID governs who you are and which applications you may call, while Azure role-based access control governs which resources a token may touch, and the large majority of access failures come from confusing the two planes. Call it the two-plane identity rule. There is an identity plane, run by Entra ID, and a resource plane, run by Azure RBAC, and an action that fails on one plane will not be fixed by changing something on the other.

Entra directory roles, such as Global Administrator, User Administrator, or Application Administrator, are roles within the directory itself. They grant the ability to manage the tenant: to create users, to configure application registrations, to reset passwords, to manage groups, to administer the directory’s own settings. What they do not grant, on their own, is any access to the resources inside an Azure subscription. A Global Administrator has supreme authority over the directory and, by default, no permission to read a storage account, restart a virtual machine, or deploy a template. The directory role lives entirely on the identity plane.

Azure RBAC roles, such as Owner, Contributor, Reader, or any of the hundreds of granular built-in roles, are assigned at a scope in the Azure resource hierarchy: a management group, a subscription, a resource group, or an individual resource. They grant the ability to perform operations on Azure resources. An assignment is always three things together: a principal, a role definition, and a scope, and the access flows down the hierarchy from the scope where it is assigned. These roles live entirely on the resource plane, and they are evaluated by Azure Resource Manager when a request reaches a resource. The full mechanics of role assignments, scope inheritance, custom roles, and ABAC conditions are covered in their own article, and they are the resource-plane half of this picture.

Does an Entra directory role grant access to Azure resources?

No, not on its own. An Entra directory role manages the directory; an Azure RBAC role grants access to resources. A Global Administrator can manage every user and app in the tenant and still receive a 403 trying to read a blob, because reading that blob requires an Azure RBAC role assignment on the resource plane, which the directory role does not provide.

The classic symptom of getting this wrong is the bewildered administrator who can do anything in the directory and cannot read a single resource, or its mirror, the resource owner who controls every subscription and cannot add a user to the tenant. Both are correct behavior once you see the two planes. There is one deliberate bridge between them: a setting that lets a Global Administrator elevate access to gain User Access Administrator rights across all subscriptions in the tenant, which exists precisely because the planes are otherwise separate and an emergency sometimes needs to cross the gap. The existence of that explicit, auditable elevation is itself the proof that the separation is intentional rather than accidental.

Working the two-plane rule in practice means that diagnosing any access problem starts with naming which plane it is on. If someone cannot manage users, configure an app registration, or reset a password, that is the identity plane, and the fix is an Entra directory role or a more granular Entra capability. If someone cannot read, write, or manage a resource, that is the resource plane, and the fix is an Azure RBAC assignment at the right scope. A surprising fraction of escalated tickets resolve the moment the responder asks which plane the failing action lives on, because the instinct to grant a broader directory role almost never fixes a resource-plane failure, and granting a broader resource role never fixes a directory-plane one. The related resource-plane failure, where an Azure operation returns AuthorizationFailed, is its own troubleshooting topic, but the first question is always the same: is this the identity plane or the resource plane.

Conditional Access: the policy layer on every sign-in

Authentication in Entra ID is not a single yes-or-no check. After an identity proves its credentials, a policy layer called Conditional Access evaluates the conditions of the sign-in and can require additional steps or block access entirely. This is the part of Entra ID that has no real Active Directory analog, and it is where the cloud identity model earns its keep, because it lets access decisions depend on signals the network perimeter never had.

A Conditional Access policy is an if-then statement over a sign-in. The conditions can include the user or group, the application being accessed, the device’s compliance state, the location of the request, the client app type, and a calculated risk level for both the user and the sign-in. The controls can grant access, require multifactor authentication, require a compliant or domain-joined device, require a specific app, or block the request. When a sign-in occurs, Entra ID authenticates the primary credential and then evaluates every applicable policy, applying the most restrictive outcome. A user signing in from a managed device on the corporate network might pass straight through, while the same user signing in from an unrecognized device in an unusual location is challenged for multifactor authentication or blocked outright.

The reason Conditional Access matters for the broader model is that it sits inside the sign-in, not beside it. An access token is issued only after the applicable policies are satisfied, so the policy layer is part of how the token comes to exist. This is why an authentication that worked yesterday can start failing today with no code change: a new Conditional Access policy now applies to that sign-in. Engineers chasing such a failure in application logs often miss it entirely, because the application did nothing wrong; the policy layer declined to issue the token. The sign-in logs in Entra ID, which record which policies applied and why a sign-in was challenged or blocked, are the right place to look, and they exist precisely because the policy layer makes the path to a token more than a credential check. The full depth of how Conditional Access evaluates a sign-in and shapes the token belongs to the authentication article, but the model to carry forward is simple: the credential gets you to the policy layer, and the policy layer decides whether a token is issued.

Tiers, limits, and the quotas that shape design

Entra ID comes in editions, and the edition determines which features are available, which has direct consequences for what you can build. A Free tier ships with every Azure subscription and Microsoft 365 plan and covers core directory services, user and group management, single sign-on, and basic security defaults. Paid editions, historically named Premium P1 and Premium P2 and sold both standalone and inside Microsoft 365 plans, unlock the features most organizations eventually need: Conditional Access, more advanced group-based licensing and dynamic groups, self-service password reset with writeback, and, at the higher tier, identity protection with risk-based policies and privileged identity management for just-in-time role activation. Because Microsoft revises edition names, bundling, and feature placement regularly, the specific feature-to-edition mapping is something to verify against the current official licensing documentation at the time you design, rather than treating any printed list as permanent.

There are also service limits that shape how you architect, and these too move over time and should be confirmed against the current documentation before you rely on a specific number. There are caps on how many directory objects a tenant can hold, on how many applications a single user or service principal can own, on how many members certain object types can have, and on throttling thresholds for the Microsoft Graph APIs you use to read and write directory data. The throttling limits in particular catch teams that script bulk directory operations, because a job that creates or updates thousands of objects in a tight loop will hit Graph throttling and must implement backoff and retry to complete. The practical guidance is to design any bulk directory automation to handle throttling responses gracefully from the start, and to confirm the current object and ownership limits for your tenant type before committing to an architecture that assumes a particular ceiling.

The edition question and the limit question intersect in one common planning trap. Teams often prototype on the Free tier, build a security design that quietly assumes Conditional Access, and then discover at deployment that the feature requires a paid edition the organization has not licensed. Because Conditional Access is the mechanism behind so much of a sound access posture, confirming the edition early, before the security design hardens around features it cannot use, saves a painful late redesign. Treat the edition as an architectural input, not an afterthought.

Failure modes and how to avoid them

Most Entra ID failures fall into a handful of families, and each family points back to one of the concepts already laid out. Recognizing the family is most of the diagnosis, because the family tells you which part of the model to check.

The first family is redirect and reply-URL mismatches. An interactive sign-in sends the user back to a redirect URI, and Entra ID will only honor a URI that is registered, matched exactly including scheme, host, port, path, and trailing slash, and registered under the correct platform type. A single-page application URI registered under the Web platform instead of the SPA platform fails even though the string looks right. A localhost URI that works in development but was never registered for the deployed URL fails the moment the app ships. A reverse proxy that rewrites the host produces a redirect Entra ID does not recognize. The error names the URI it received, so the fix is mechanical: read the received URI from the error and register it exactly, under the right platform. Chasing consent or credentials here wastes time, because the failure is purely a registration mismatch.

The second family is consent and permission errors. An application requests a permission that has not been consented, or a daemon is configured with delegated permissions and then runs with no user present, or a tenant restricts user consent so an ordinarily self-service permission now waits on an administrator. The signature of this family is that the code is fine and the directory state is the problem. The fix is to match the permission type to whether a user is present, application permission for unattended workloads and delegated permission for user-present ones, and to secure the right consent from the right person. When the permission requires admin consent, no amount of retrying as an ordinary user will succeed.

The third family is application-not-found errors, where Entra ID cannot locate the application identified by the client ID. The cause is almost never a corrupt registration that needs recreating. It is usually the wrong client ID, authentication against the wrong tenant, a multi-tenant application that was never consented into the resource tenant so no service principal exists there, or the use of a common endpoint where a tenant-specific authority was required. The fix is to verify the client ID against the correct tenant and to confirm a service principal exists locally, not to rebuild the app object. This family is the application-object-versus-service-principal distinction showing up as an error code, and seeing it that way points straight to the lookup that resolves it.

The fourth family is credential expiry. A registration that authenticates with a client secret stops working when the secret lapses, producing an invalid-client failure. The fix is to rotate the secret before it expires, and the better long-term fix is to move off stored secrets entirely toward certificates, managed identities, or federated credentials, so there is no expiry to miss. Teams that operate many registrations benefit from tracking secret expiry centrally, because a silent lapse turns into an outage that looks far more dramatic than its cause.

The fifth family is the two-plane mistake already covered at length: granting a directory role to fix a resource-plane failure or the reverse. The tell is that the access being requested and the access being granted live on different planes. The fix is to grant on the plane where the failing action actually lives, an Azure RBAC assignment for a resource operation and an Entra capability for a directory operation.

What is the most common Entra ID misdiagnosis?

The most common misdiagnosis is treating a resource-plane access failure as an identity-plane problem, then escalating the directory role instead of assigning the right Azure RBAC role. A user gets a 403 reading a resource, someone makes them a directory administrator, the 403 persists, and confusion deepens. The action lives on the resource plane; only an RBAC assignment at the right scope fixes it.

Across all five families, the discipline that prevents the most wasted effort is to name the principal and the plane before changing anything. Which principal is actually making the request, a user, a service principal, or a managed identity, and is the failing action on the identity plane or the resource plane. Those two questions route almost every Entra ID failure to the right fix on the first attempt, and they are the reason the conceptual model in this guide is worth holding precisely rather than approximately.

Hybrid identity: when Entra ID meets on-premises Active Directory

Many organizations do not start in the cloud; they run an established on-premises Active Directory and adopt Entra ID alongside it. The bridge between the two is identity synchronization, and understanding it clears up another set of expectations. A synchronization tool, historically Azure AD Connect and now Microsoft Entra Connect, replicates identities from the on-premises directory into the Entra ID tenant so that the same user can sign in to both worlds. What flows across is the identity and selected attributes, not the on-premises directory’s operational model; the synchronized users live in Entra ID as cloud identities that happen to originate on-premises.

Authentication in a hybrid setup can take several shapes, and the choice has real consequences. Password hash synchronization replicates a hash of the password hash into the cloud so Entra ID can authenticate the user directly, which is simple and resilient. Pass-through authentication validates the password against the on-premises directory in real time without storing it in the cloud, keeping validation on-premises at the cost of depending on the on-premises connectors being available. Federation, historically through Active Directory Federation Services, hands authentication off entirely to the on-premises identity provider. Each option trades simplicity, control, and dependency differently, and the right choice depends on the organization’s requirements rather than a single best answer. The recurring lesson is that synchronization makes the cloud identity available; it does not turn Entra ID into the on-premises directory, and the cloud features such as Conditional Access still operate on the cloud side regardless of where the password is checked.

The hybrid story is also where the rename to Entra ID pays off conceptually. An administrator steeped in the on-premises model naturally expects synchronized objects to behave like directory objects they know, and many of the surprises in a hybrid deployment come from that expectation. Approaching the synchronized identities as cloud identities that originate on-premises, governed by the cloud identity model, sets the right expectations and avoids the trap of reasoning about them as though group policy and organizational units carried across, which they do not.

External identities: customers and partners

Entra ID is not only for an organization’s own employees. Two capabilities extend it outward. Business-to-business collaboration lets you invite external people as guests into your tenant, so a partner authenticates against their own home tenant and is recognized as a guest in yours with access to the specific resources you grant. Business-to-consumer scenarios, delivered historically through Azure AD B2C and folded into the broader external identities and external tenant model, let you stand up a customer-facing identity system where the people signing in are consumers using social accounts or local accounts you manage for the application.

The distinction between these matters because they target different audiences and behave differently. Guest collaboration is about extending your workforce directory to trusted external people, and the guests carry an identity from somewhere else. Customer identity is about giving an application its own sign-up and sign-in experience for the public, with customization of the user journey and support for identity providers your customers already use. Reading documentation, it is worth confirming which model a feature applies to, because a capability available for workforce guests may not exist in the customer model or may behave differently. The practical guidance is to decide early whether the people signing in are partners you are extending trust to or customers you are serving, because that decision selects the model and the model shapes everything downstream.

How a resource validates a token

Issuing a token is only half the story; the other half is what a protected resource does when one arrives, and understanding validation closes the loop on the whole token model. When an access token reaches an API, the API does not call back to Entra ID on every request. Instead it validates the token locally and cryptographically, which is what makes the token model scale. The token is signed by Entra ID with a private key, and the API verifies that signature using Entra ID’s published public signing keys, confirming the token is authentic and unaltered. Because the signing keys rotate, a well-behaved API fetches and caches the current keys from a published metadata endpoint and refreshes them, rather than pinning a single key that will eventually be retired.

Beyond the signature, the API checks a small set of claims, and most token rejections trace to one of them. The audience claim names the resource the token was minted for, and an API must confirm the token was intended for it and not for some other resource; a token issued for one API will be rejected by another even if the signature is perfect, which is the audience-mismatch failure engineers hit when they reuse a token across services. The issuer claim names the authority that minted the token, and the API confirms it trusts that issuer, which in a multi-tenant API means validating the tenant the token came from. The expiry claim bounds the token’s lifetime, and the API rejects anything past it, which is why short-lived access tokens paired with refresh tokens are the normal pattern rather than long-lived tokens that linger as a risk. The scope or roles claims carry what the token is authorized to do, and the API reads them to make its own authorization decision.

Why is my token rejected even though sign-in succeeded?

A successful sign-in proves identity, but the API still validates the access token independently, and the usual culprit is the audience claim. A token minted for one resource is rejected by another, even with a valid signature, because the audience does not match. Confirm the token’s audience names the API you are calling, and that the issuer and expiry check out.

This is where the token-flow map and the ID-token-versus-access-token rule pay off concretely. An application that sends an ID token to an API will be rejected, because the ID token’s audience is the client application, not the API; the API wants an access token whose audience is the API itself. A backend that requests a token for the wrong resource identifier ends up with an audience the target API will not accept. Reading the actual claims in a rejected token, the audience, the issuer, the scopes, and the expiry, turns a vague rejection into a precise statement of what does not line up, and almost every token rejection resolves to one of those four checks failing.

Microsoft Graph: the API the permissions are about

When discussions of Entra ID permissions mention reading mail, listing users, or managing groups, the API on the other end is almost always Microsoft Graph, the unified API surface for Microsoft 365 and Entra ID data. Graph is where the delegated-versus-application permission distinction becomes tangible, because the permissions you grant on a registration are overwhelmingly Graph permissions, and the scopes in your tokens are Graph scopes. An application that reads user profiles, sends mail, manages calendar events, or queries directory objects does so through Graph, presenting an access token whose audience is Graph and whose scopes Graph reads to decide what the call may do.

Understanding that Graph is the destination clarifies a few recurring points. The permission names you wrestle with, the ones that need admin consent and the ones a user can grant, are defined by Graph and the other resource APIs, not invented by your application. The throttling limits that catch bulk directory automation are Graph’s limits, and the backoff your script must implement is backoff against Graph. The difference between a delegated permission to read the signed-in user’s own profile and an application permission to read every user in the tenant is a difference in Graph permissions, and choosing between them is choosing what your token is allowed to ask Graph to do. Treating Graph as the concrete API the abstract permissions act on makes the permission model less abstract and the consent decisions more grounded, because you can ask exactly what data and what operations a given permission opens up.

Privileged access and least privilege over time

A mature Entra ID posture does not leave powerful roles permanently assigned, because a standing Global Administrator is a standing risk whether or not the account is doing anything privileged at the moment. The higher paid edition includes privileged identity management, a capability for just-in-time role activation: instead of holding a privileged directory role all the time, an eligible administrator activates it for a bounded window when they need it, often with approval and justification, and the elevated rights expire automatically afterward. The effect is that the powerful roles exist as eligibility rather than as constant possession, which shrinks the window in which a compromised account carries dangerous privilege.

This sits alongside the broader least-privilege discipline that applies on both planes. On the identity plane, granting the narrowest directory role that accomplishes the task, rather than reaching for Global Administrator out of habit, limits the blast radius of any single compromised credential, and Entra ID offers many granular administrative roles precisely so that broad roles are not the only option. On the resource plane, the same instinct applies to Azure RBAC, where a specific built-in role at a tight scope is almost always preferable to Owner or Contributor assigned broadly. The recurring lesson across both planes is that least privilege is a deliberate design rather than a default, and the convenient broad grant is the one that comes back as an incident. Time-bound activation extends least privilege into the dimension of time, so that even necessary privilege is held only as long as it is needed.

Identity protection and the risk signals behind a sign-in

Part of what makes Entra ID a cloud identity system rather than a credential checker is that it reasons about risk on every sign-in. The higher paid edition includes identity protection, which calculates a risk level for both the user and the individual sign-in using signals such as impossible-travel patterns, sign-ins from anonymizing networks, leaked-credential matches, and unfamiliar behavior. Those risk levels feed back into Conditional Access, so a policy can demand multifactor authentication or block access specifically when the risk is elevated, rather than treating every sign-in identically.

This closes a loop that the on-premises perimeter model could not. In a network-trust world, a valid credential from inside the perimeter was largely trusted, and a stolen credential used from inside looked the same as a legitimate one. In the identity model, the sign-in itself carries a calculated risk, and the policy layer can respond to that risk in the moment. The practical consequence for engineers is that authentication outcomes are not purely a function of correct credentials and correct configuration; they also depend on signals that vary per sign-in, which is one more reason the sign-in logs, recording the risk assessment and the policies that applied, are the authoritative place to understand why a particular sign-in was challenged or allowed.

The consent framework and the illicit consent risk

The consent framework that gates application permissions is a security feature, and like most security features it has a misuse that is worth naming. When an application asks a user to consent to delegated permissions, the user is granting that application access to act on their behalf within those permissions. A malicious application can exploit this by presenting a convincing consent prompt and requesting permissions that, once granted, let it read mail or files on the user’s behalf, an attack pattern often called illicit consent grant. The defense is on the directory side: tenants can restrict user consent so that only administrators approve applications, or allow user consent only for applications from verified publishers and for low-risk permissions.

For engineers building legitimate applications, the consequence is that the consent experience in a hardened tenant is different from the open default. An application that relied on users self-consenting may find that, in a tenant restricting user consent, an administrator must approve it before anyone can use it, which changes onboarding and is one reason an application that works in a permissive test tenant stalls in a locked-down production one. Understanding that the consent framework is a deliberate control rather than a formality explains both the security posture organizations adopt and the friction a well-designed application should anticipate. Requesting only the permissions actually needed, and being ready for administrator approval rather than assuming self-consent, is the design that survives contact with a security-conscious tenant.

When to use Entra ID and when to reach for something else

Entra ID is the right identity foundation for nearly any application that runs on Azure, integrates with Microsoft 365, or needs single sign-on across cloud and SaaS applications. If your workload authenticates users in an organizational context, secures access to Azure resources, or calls Microsoft Graph and other Microsoft APIs, Entra ID is not merely an option but the default that everything else is built to expect. Its managed identities remove stored credentials from Azure-hosted workloads, its Conditional Access enforces a modern access posture, and its token model speaks the protocols web and mobile applications already use.

There are boundaries worth naming honestly. If you need a domain controller, Kerberos authentication, LDAP queries, or group policy for domain-joined machines, the everyday Entra ID does not provide them, and the managed Entra Domain Services exists for the narrow case of running directory-aware legacy workloads in the cloud. If you are building a consumer application and the workforce model does not fit, the external identities and customer model is the right tool rather than forcing employees-and-guests semantics onto consumers. And if your application lives entirely outside the Microsoft ecosystem with no Azure resources, no Microsoft 365, and no need for Microsoft single sign-on, then a general-purpose identity provider may fit your stack more naturally, though even then Entra ID is a capable standards-based OAuth and OpenID Connect provider that many non-Microsoft applications use precisely because it speaks those open protocols well.

The decision rule is straightforward. Use Entra ID when the workload touches Azure, Microsoft 365, or the Microsoft identity ecosystem, which covers the overwhelming majority of Azure engineering. Reach for the managed domain service when you specifically need legacy directory protocols. Reach for the customer identity model when the people signing in are consumers rather than employees or partners. And evaluate a third-party provider only when your stack has no Microsoft identity surface at all, knowing that Entra ID’s standards support means it can usually serve that case too.

Exposing an API and defining application roles

So far the discussion has treated applications as clients that call APIs, but an application registration can also describe an API that other applications call, and this is where scopes and application roles come from. When your application is itself a protected API, its registration exposes scopes, the named permissions a calling application can request on behalf of a user, and application roles, the named permissions a calling application can hold as itself. A client that wants to call your API requests one of your exposed scopes or is granted one of your application roles, and the access token it receives carries that scope or role as a claim. Your API then reads that claim and enforces it, deciding what the caller may do based on what it presented.

This mirrors, from the API author’s side, the consent and permission model that clients experience. The scopes you expose are the delegated permissions clients request when a user is present, bounded as always by what the user can do. The application roles you define are the application permissions clients hold when acting as themselves, which is why granting one to a client is an administrator decision rather than a user one. Designing an API’s exposed surface well means defining scopes and roles that are granular enough to support least privilege, so that a client needing read access does not have to request write access because no read-only scope exists. The full treatment of exposing an API, the manifest, and the scopes-and-roles design lives in the app registrations deep dive, but the model to carry is symmetric: the permissions clients request are the scopes and roles some API author defined, and when you author an API you are on the other side of that relationship.

Reading the sign-in and audit logs

Because Entra ID makes authentication a multi-step process with a policy layer and risk signals, the logs that record what happened are not a convenience but the primary diagnostic surface, and learning to read them resolves the failures that application logs cannot explain. The sign-in logs record every authentication: which identity signed in, against which application, from where, on what device, which Conditional Access policies applied and what they required, whether multifactor authentication was triggered, and the result with a reason code. When a sign-in is challenged or blocked, this is where the why lives, and it is almost always more informative than the generic error the application surfaces to the user.

The audit logs record changes to the directory itself rather than authentications: who created or modified a user, who granted consent to an application, who changed a Conditional Access policy, who assigned a directory role. When an application’s behavior changes without a code deployment, the audit log often reveals a directory change that explains it, such as a newly applied policy or a revoked consent. Reading these two logs together, sign-in logs for why an authentication behaved as it did and audit logs for what changed in the directory, covers the large majority of operational questions about an Entra ID tenant. The recurring mistake is to debug an authentication failure entirely in application code when the answer is sitting in the sign-in logs, recorded by the policy layer that actually made the decision. Building the habit of checking the sign-in logs first, before assuming a code bug, saves hours on exactly the failures that look most mysterious from inside the application.

Where do I look first when an authentication problem appears?

Start in the Entra ID sign-in logs. They record the identity, the application, the location and device, which Conditional Access policies applied, whether multifactor authentication was required, and the result with a reason code. Most authentication failures are explained there, by the policy layer that made the decision, long before the application code is the issue.

Tenant-wide settings that quietly change behavior

A number of tenant-level settings change how every application in the directory behaves, and because they are set once and rarely revisited, they are a frequent source of behavior that seems inexplicable until you find the switch. The user consent setting, already discussed, determines whether ordinary users can consent to applications or whether an administrator must, and flipping it to the restrictive option changes onboarding for every new application at once. Security defaults, a baseline set of protections Microsoft can enable for a tenant, enforce practices such as requiring multifactor authentication for administrators, and a tenant running on security defaults behaves differently from one running custom Conditional Access policies. Guest access settings govern what external guests can see and do once invited, and a restrictive setting can surprise a partner who expected broader visibility.

The lesson is that an application’s behavior is shaped not only by its own registration and the permissions it holds but by the tenant it runs in, and the same application can behave differently across two tenants because their tenant-wide settings differ. This is one more reason an application that works in a permissive development tenant can stumble in a hardened production one, and it is why, when behavior differs across environments with identical application configuration, the tenant settings are the place to compare. Treating the tenant as an active part of the system, with settings that govern consent, baseline security, and guest behavior, rather than as an inert container, prevents a category of cross-environment surprises that otherwise look like phantom bugs.

How applications actually integrate with the identity platform

Engineers rarely implement OAuth flows by hand, and they should not, because the flows have security-critical details that are easy to get wrong, such as validating state, handling PKCE correctly, caching tokens safely, and refreshing them at the right moment. Microsoft provides the Microsoft Authentication Library, MSAL, for the major platforms and languages, and using it is the supported path for client applications. MSAL handles acquiring tokens through the right flow for the application type, caching them so a user is not prompted repeatedly, and refreshing them silently when they expire. An application typically asks MSAL for a token for a specific resource and a specific set of scopes, and MSAL either returns a cached valid token, refreshes one silently, or triggers an interactive sign-in, abstracting the flow selection that the token-flow map lays out conceptually.

The reason this matters for the mental model is that the library does not change the model; it implements it. When MSAL acquires a token for a resource, it is requesting an access token whose audience is that resource and whose scopes are the permissions the application holds. When it caches and silently refreshes, it is using the refresh token to obtain new short-lived access tokens without a fresh sign-in. When it triggers an interactive prompt, the Conditional Access policy layer still evaluates the sign-in, so a library-driven authentication can still be challenged or blocked by policy. Understanding the model therefore makes the library legible: a token MSAL returns is the same token this guide has described, with the same claims a resource validates, and a failure MSAL surfaces points back to the same families, a wrong audience, a missing consent, a policy block, or an expired credential. The library spares you the protocol plumbing; it does not spare you the model, and engineers who know the model debug library behavior far faster than those who treat MSAL as a black box.

For workloads rather than client applications, the integration is often even simpler. An Azure-hosted workload using a managed identity does not need to manage a credential at all, and the Azure SDKs provide a credential abstraction that, by default, discovers the managed identity at runtime and acquires tokens through it, so the same code can run locally under a developer’s identity and in Azure under the workload’s managed identity without change. This is the practical payoff of managed identities: the code asks for a token, the platform supplies the credential, and there is nothing in source control or configuration to leak or rotate. The choice between a managed identity and a classic service principal credential is consequential enough that the comparison of when each fits, by secret lifecycle and where the workload runs, is treated separately, but the default for Azure-hosted code is clear: reach for the managed identity first.

Common patterns engineers actually build

A few patterns recur often enough that recognizing them shortcuts a lot of design. A web application that signs users in and calls an API on their behalf uses the authorization code flow with PKCE, holds a confidential client credential (a certificate, ideally), requests delegated scopes for the downstream API, and relies on Conditional Access in the tenant to enforce the access posture. The access failures it hits are redirect-URI mismatches during sign-in and consent prompts for the delegated scopes, both of which the families above explain.

A backend service that runs on a schedule with no user, such as a nightly job that reads directory data or processes mailboxes across the organization, uses the client credentials flow with application permissions, requires admin consent for those permissions, and authenticates as its own service principal. Its characteristic failure is the delegated-versus-application mix-up, where it was configured for a user that is not present at runtime. Moving such a service onto a managed identity, where the workload runs in Azure, removes its stored credential and the rotation burden that comes with it.

A multi-tenant software-as-a-service application that other organizations sign up for is its own recognizable shape, and it leans hard on the application-object-versus-service-principal distinction. The registration lives once in the publisher’s tenant, marked multi-tenant, while a separate service principal is provisioned in each customer tenant the first time someone there consents to the application. The customer’s administrator grants consent for the permissions the application needs, which creates and configures that local service principal, and from then on users in that tenant authenticate against their own tenant’s authority. The failures this pattern produces are precisely the application-not-found family: a customer who never completed consent has no service principal, so authentication against their tenant fails until an administrator consents. Designing such an application means planning the onboarding consent step deliberately, requesting only the permissions genuinely required so administrators are comfortable approving, and expecting that hardened customer tenants restricting user consent will route every new sign-up through an administrator rather than letting individual users self-consent.

An application that exposes its own API to other applications defines scopes and application roles on its registration, validates incoming access tokens by signature, audience, issuer, and expiry, and reads the scope or role claims to authorize each call. Its failures live on the validation side: tokens with the wrong audience, signing keys that were not refreshed, or callers that requested a scope the API never exposed. A workload that needs to reach Azure resources, finally, uses a managed identity for the token and an Azure RBAC role assignment at the right scope for the resource access, which is the two-plane rule expressed as an architecture: identity from Entra ID, resource access from RBAC, and a failure on either plane fixed on that plane. Seeing a new requirement as one of these patterns, rather than as a blank-page design, lets you start from a known-good shape and adjust, and it connects the abstract model directly to the concrete thing you are about to build.

How to think about Microsoft Entra ID

If you carry one model away from this guide, make it the two-plane separation. Entra ID is the identity plane: it answers who you are, decides which applications you may call, evaluates the conditions of every sign-in, and issues the tokens that prove all of it. Azure RBAC is the resource plane: it decides which resources a token may touch, through role assignments at a scope. An action that fails on one plane is fixed on that plane and not the other, and the instinct to grant a broader directory role to fix a resource problem is the single most common and most fruitless move in Azure access troubleshooting.

Underneath that headline sit the supporting concepts, each of which earns its place. The tenant is the boundary that contains every identity, application, and policy, and authentication always happens against a specific tenant. Identities come as users, groups, and the application and workload principals that trip up human-centric intuition, with managed identities as the safest default for Azure-hosted code. An application registration is the global definition of an app, while the service principal is its local instance in a tenant that actually holds consent and roles. Tokens come in three kinds with distinct jobs, issued through flows chosen by what kind of application is signing in and whether a user is present. Permissions are delegated when a user is present and application-scoped when none is, with admin consent gating the powerful unattended case. Conditional Access sits inside the sign-in and decides whether a token is issued at all.

Hold those pieces together and Entra ID stops being a wall of blades and error codes and becomes a coherent system you can reason about. An authentication problem becomes a question of which token, which flow, which principal, and which plane. A design question becomes a matter of choosing the right principal, the right permission type, the right edition for the features you need, and the right consent. The reward for learning the model precisely rather than approximately is that the next AADSTS error, the next puzzling 403, and the next access design all resolve faster, because you already know which part of the system to look at.

The verdict

Microsoft Entra ID is the identity and access platform that almost every Azure engineering decision eventually depends on, and the engineers who work with it confidently are the ones who internalized that it is not cloud Active Directory but a cloud-native identity system with its own model. The rename was a signal worth heeding. The folk model imported from the on-premises directory causes a steady drip of wrong expectations, while the correct model, built on tenants, identities, registrations and service principals, tokens and flows, permissions and consent, Conditional Access, and above all the two-plane separation of identity from resource access, makes the whole service legible. Learn it once, hold it precisely, and the payoff compounds across every authentication you debug and every access design you ship. To put the model to work, register an app, request a token, and watch each piece behave; you can run the hands-on Azure labs and command library on VaultBook to trace a real token from sign-in to API call and see the two planes in action.

Frequently Asked Questions

Q: What is Microsoft Entra ID and what does it do?

Microsoft Entra ID is Microsoft’s cloud-based identity and access management platform, formerly named Azure Active Directory. Its job is to establish who or what is making a request, prove that identity with a verifiable token, decide which applications that identity may call, and evaluate the conditions of every sign-in before a token is issued. It is the identity provider behind Microsoft 365, the authority that secures Azure subscriptions, the engine for single sign-on to thousands of SaaS applications, and the issuer of short-lived tokens to workloads. It speaks OAuth 2.0 and OpenID Connect rather than the Kerberos and LDAP of on-premises directories, which makes it built for web, mobile, and cloud applications rather than for domain-joined machines on a trusted network.

Q: How does Entra ID differ from on-premises Active Directory?

They solve different problems with different protocols. On-premises Active Directory Domain Services manages domain-joined Windows machines on a trusted network using Kerberos and LDAP, with organizational units and group policy as its tools. Entra ID manages identities for cloud and SaaS applications across the open internet using OAuth and OpenID Connect, and it has no domain controller, no group policy, and no organizational units. Entra ID trusts tokens rather than the network, issuing a scoped, time-limited credential that every protected resource validates on its own. The two are complementary rather than equivalent: many organizations run both and synchronize identities between them. The rename from Azure Active Directory to Entra ID was partly meant to break the assumption that the cloud service is simply a hosted copy of the on-premises one.

Q: How does an application get a token from Entra ID?

An application requests a token through an OAuth 2.0 grant flow, and which flow it uses depends on what the application is and whether a user is present. An interactive web or mobile application uses the authorization code flow with PKCE: the user signs in, the application receives a short-lived code, and it exchanges that code for an ID token, an access token, and usually a refresh token. A daemon or backend service with no user uses the client credentials flow, presenting its own secret or certificate to receive an application-level access token. An Azure-hosted workload uses its managed identity to obtain a token from the local identity endpoint with no credential in code. In every case the application authenticates against a specific tenant’s authority, and the issued token carries claims that the receiving resource validates.

Q: What is the difference between delegated and application permissions?

A delegated permission lets an application act on behalf of a signed-in user, and the effective access is the intersection of what the application is granted and what the user can already do, so the application never exceeds the user’s own reach. An application permission lets the application act as itself with no user present and no user-scoped ceiling, which is why it is used by unattended daemons and why it always requires admin consent from a privileged administrator. The most common mistake is configuring a daemon with delegated permissions: it works in testing while a developer is signed in, then fails in production when it runs with no user to delegate from. Match the permission type to whether a user is present at runtime.

Q: How do Entra directory roles differ from Azure RBAC roles?

They operate on two separate planes. Entra directory roles, such as Global Administrator or User Administrator, govern the directory itself: creating users, configuring app registrations, managing groups, and administering tenant settings. Azure RBAC roles, such as Owner, Contributor, or Reader, govern operations on Azure resources and are assigned at a scope in the resource hierarchy. A directory role grants no resource access on its own, and a resource role grants no directory administration. This is why a Global Administrator can manage every user and still get a 403 reading a storage blob, because reading the blob requires an Azure RBAC assignment on the resource plane. There is one deliberate bridge, an elevate-access setting, which exists precisely because the planes are otherwise separate.

Q: What is an app registration and why do I need one?

An app registration is an application’s identity record in Entra ID, and any application that signs users in or calls a protected API needs one. The registration holds the client ID that uniquely names the application, the credentials it uses to prove itself, the redirect URIs Entra ID is allowed to return users to, the API permissions it requests, and any scopes or roles it exposes if it is itself an API. Without a registration, Entra ID has no record of the application and cannot issue or validate tokens for it. The registration is the global definition of the application, the blueprint, and it is the thing you configure when you control how the application behaves during authentication.

Q: What does it mean that Azure AD was renamed to Microsoft Entra ID?

In 2023 Microsoft renamed Azure Active Directory to Microsoft Entra ID, with no change to the service’s tenant IDs, identifiers, or core functionality. The rename was a branding and conceptual move: Entra is the family name for Microsoft’s identity and access products, and Entra ID is the directory itself. Because the older name remains in years of documentation, portal screenshots, community answers, and error codes, you will encounter both names for a long time and should treat them as the same service. The new name also nudges users away from assuming the product is a cloud copy of on-premises Active Directory, which was a persistent source of misunderstanding under the old name. Verify current branding against official documentation, since Microsoft adjusts product names periodically.

Q: What is a tenant in Microsoft Entra ID?

A tenant is a dedicated, isolated instance of the Entra ID directory that an organization owns. It is the trust boundary that contains all of the organization’s identities, application registrations, groups, and policies, and it is identified by a globally unique tenant ID and one or more domain names, including a default of the form yourcompany.onmicrosoft.com. Authentication always happens against a specific tenant, and a token is stamped with that tenant’s identity, which is why an account from one tenant is not automatically trusted in another. A tenant holds identities, while an Azure subscription holds resources and billing; one tenant can be associated with many subscriptions, and the two are governed by separate role systems.

Q: Why does my service principal have access but my app registration does not?

Because they are two objects with two jobs. The app registration, the application object, is the global definition of the application and is where you configure its identity, credentials, and requested permissions. The service principal, shown as the enterprise application, is the local instance of the application in a specific tenant, and it is what actually holds the consented permissions and the role assignments. You grant access on the service principal, not on the registration. When access seems present on one and absent on the other, you are looking at the difference between the application’s definition and its local instance. In a multi-tenant scenario the registration lives only in the publisher’s tenant while a separate service principal is provisioned in each consuming tenant.

Q: What are the three token types in Entra ID and what is each for?

There are ID tokens, access tokens, and refresh tokens. An ID token proves to a client application who the user is; it is the OpenID Connect addition and is meant to be read by the application that requested the sign-in. An access token authorizes a call to a protected API; it is consumed by that API, which validates it and reads its claims to decide whether to proceed. A refresh token is a longer-lived credential a client presents to obtain new access tokens silently when the short-lived ones expire, sparing the user a fresh sign-in. The governing rule is that an ID token proves identity to the app while an access token authorizes an API, so most token confusion comes from using one where the other belongs.

Q: Why does my daemon application fail in production but work in testing?

The usual cause is that the daemon is configured with delegated permissions rather than application permissions. In testing a developer is signed in, so the application can act on the developer’s behalf and the delegated permission works. In production the daemon runs unattended with no user, so there is no one to delegate from and the call fails. The fix is to grant the daemon an application permission, which lets it act as itself with no user present, and to secure admin consent for that permission, since application permissions always require an administrator. This is a textbook case of matching the permission type to whether a user is present at runtime rather than at test time.

Q: What is a managed identity and how does it relate to Entra ID?

A managed identity is a special service principal that Azure creates and manages for a workload such as a virtual machine, app service, or function, with no secret or certificate for you to store or rotate. The platform handles the underlying credential entirely, so when code running under the identity needs a token to call an Azure API, it asks the local identity endpoint and receives one without any credential in your code or configuration. Managed identities come as system-assigned, tied to a single resource’s lifecycle, or user-assigned, created standalone and attachable to many resources. They are the right default for Azure-hosted workloads precisely because they remove the stored credential that is otherwise the most common thing to leak, and they live in your tenant as principals you can grant roles to.

Q: Why do I get a 403 on a resource even though I am a Global Administrator?

Because reading or managing a resource is a resource-plane action governed by Azure RBAC, and Global Administrator is a directory-plane role governed by Entra ID. The directory role lets you manage users, applications, and tenant settings, but it grants no access to the contents of an Azure subscription by default. To read the resource you need an Azure RBAC role, such as Reader or a more specific built-in role, assigned at the right scope, which could be the subscription, the resource group, or the individual resource. This is the two-plane rule in its most common form: the failing action is on the resource plane, so escalating the directory role will not help and an RBAC assignment will.

Q: How does Conditional Access affect whether I get a token?

Conditional Access sits inside the sign-in, not beside it. After Entra ID validates the primary credential, it evaluates every applicable Conditional Access policy, applying the most restrictive outcome, and a token is issued only if those policies are satisfied. A policy is an if-then statement over signals like the user, the application, the device’s compliance, the location, and a calculated risk level, with controls that can grant access, demand multifactor authentication, require a compliant device, or block the request. This is why an authentication that worked yesterday can fail today with no code change, because a new policy now applies. The Entra ID sign-in logs record which policies applied and why, which is the right place to diagnose such a failure rather than the application’s own logs.

Q: What is the difference between a member user and a guest user?

A member user is one of the organization’s own people, created directly in the tenant or synchronized into it from an on-premises directory, and they authenticate as a full participant in the tenant. A guest user is an external person invited into the tenant through business-to-business collaboration; the guest authenticates against their own home tenant and is then recognized as a guest in yours, with access to the specific resources you grant. Guests let you extend access to partners and contractors without creating full accounts for them, and they embody the tenant trust boundary working as intended, since their underlying identity lives elsewhere while their guest status lives in your directory.

Q: When should I use a certificate instead of a client secret for an app?

Prefer a certificate for any production confidential client. A client secret is a string, easy to create and easy to leak, and it has an expiry you must track and rotate before it lapses, or the application stops authenticating with an invalid-client error. A certificate is harder to exfiltrate and stronger as a credential. The strongest option, where it fits, is to use no stored credential at all: a managed identity for Azure-hosted workloads or a federated credential for external workloads removes the secret entirely, so there is nothing to rotate and nothing to leak. The choice is a security and operational trade-off, and moving off stored secrets is the durable direction for credentials that would otherwise need constant rotation.

Q: Does synchronizing on-premises Active Directory turn Entra ID into a domain controller?

No. Synchronization, through Microsoft Entra Connect, replicates identities and selected attributes from the on-premises directory into the Entra ID tenant so the same user can sign in to both. What flows across is the identity, not the on-premises operational model: there is still no group policy, no organizational units, and no Kerberos domain controller in Entra ID. The synchronized users live in Entra ID as cloud identities that originate on-premises, governed by the cloud identity model, and cloud features like Conditional Access still operate on the cloud side regardless of where the password is validated. Treating synchronized objects as cloud identities rather than as on-premises directory objects sets the right expectations and avoids a common class of hybrid surprises.

Q: How do I choose between workforce and external customer identity in Entra ID?

Decide who is signing in. If the people are your own employees, contractors, or trusted partners, use the workforce model, where partners come in as guests through business-to-business collaboration. If the people are consumers of a customer-facing application, use the external identities and customer model, historically delivered through Azure AD B2C, which gives the application its own sign-up and sign-in experience with social or local accounts and a customizable user journey. The two behave differently, and a feature available for workforce guests may not exist or may differ in the customer model, so confirm which model a capability applies to. Making this choice early matters, because it selects the model and the model shapes the rest of the design.

Q: Why can Entra ID not find my application during authentication?

This is the application-not-found family, and it is rarely a corrupt registration. The usual causes are a wrong or mistyped client ID, authentication against the wrong tenant, a multi-tenant application that was never consented into the resource tenant so no service principal exists there, or the use of a shared common endpoint where a tenant-specific authority was needed. The fix is to verify the client ID against the correct tenant and confirm that a service principal exists locally, not to recreate the application object. Seeing this error as the application-object-versus-service-principal distinction surfacing points you straight to the lookup that resolves it, and recreating the registration usually changes nothing because the registration was never the problem.

Q: Is Entra ID a good identity provider for a non-Microsoft application?

It can be. Entra ID is a standards-based OAuth 2.0 and OpenID Connect provider, so applications outside the Microsoft ecosystem can use it for sign-in and token issuance through those open protocols, and many do. It is the natural default when an application touches Azure, Microsoft 365, or Microsoft APIs, and it remains a capable choice even when it does not, because the protocols it speaks are the same ones general-purpose identity providers use. The case for evaluating a third-party provider instead is strongest when your stack has no Microsoft identity surface at all and you have other reasons to prefer a different vendor. Even then, Entra ID’s solid standards support means it usually serves the scenario well rather than poorly.