Entra ID Foundations Get a Refresher as Agent Identity Reshapes Cloud Strategy

Microsoft's identity service has gone through enough name changes to confuse even the people who sell it, but the underlying questions enterprises ask have not changed much: what exactly is this thing, and how do my applications and now my agents authenticate against it? A new technical series from Journey of the Geek tackles that head on, and the timing is not accidental. The growing push toward AI agents in Microsoft's cloud estate has dragged identity back to the center of architecture conversations, and a lot of teams are discovering their mental model of Entra ID was, in the author's words, too ivory tower.

What changed

The practical shift is that agents now need identities, and Microsoft has answered with a growing family of service principal types: managed identities, Agent Identity Blueprints, Agent Identities, and Agent Users. None of that makes sense until you understand the plumbing underneath, which is why the series starts by going back to basics. If you plan to build agents through Microsoft Foundry, Copilot Studio, or any of the other services Microsoft is bolting agent support onto, the request flows for OIDC authentication and OAuth on-behalf-of are no longer optional knowledge. They are the foundation the entire Entra ID Agent Identity feature builds on.

Stripped of marketing language, Entra ID does two core things. It is an identity store holding human and non-human security principals along with their attributes and credentials, and it is an authentication service that can act as an OAuth authorization server, an OIDC identity provider, a SAML IdP or SP, and even a Kerberos or LDAP provider. Those services power Microsoft's own clouds like M365, Azure, and Dynamics 365, and they can be extended to third-party applications through the supported protocols. Everything is partitioned into tenants, each one a distinct identity boundary, with cross-tenant access handled through features like Entra ID External ID.

The distinction that trips everyone up

The heart of the first post is the difference between an application object, commonly called the app registration, and a service principal. This is the single most misunderstood pairing in the platform, and getting it wrong leads to permission grants that go nowhere and multi-tenant apps that refuse to authenticate.

Think of the application object as the globally unique definition of an application. There is exactly one, and it lives in the tenant where the app was registered. The cleanest analogy offered is the OAuth client registration. It carries the client id (the appId), the audience (identifierUris), the scopes it supports (oauth2PermissionScopes), the redirect URIs, and any credentials in the form of a secret, certificate, or federated credential that let it authenticate as a confidential client. In the demo backend API used throughout the series, that object exposes a single delegated scope, user_impersonation, and requests access to a downstream resource through its requiredResourceAccess block.

The service principal is the other half. It is the local security principal that represents the application inside a given tenant. Permissions are granted to the service principal, not the application object, and the application exercises those permissions through it when it does something like query the Microsoft Graph API. One application object can have many service principals, one per tenant, which is precisely what makes multi-tenant applications work. Other organizations create a service principal for your app in their tenant, and that stub identity is what lets your application authenticate their users and reach their resources. Microsoft's own framing, the application object as the template and the service principal as the security principal, holds up well as a one-line summary.

How the demo proves it out

Rather than hide behind SDKs, the series works directly against the REST APIs to expose the gory details. The reference solution is deliberately small: a Flask frontend and a FastAPI backend, both in Python. The frontend authenticates the user through Entra ID and receives an OIDC id token, then pulls additional attributes from the Microsoft Graph API using the client credentials flow, including group membership and the handling of nested groups. From there it calls a /story endpoint on the backend, which uses the OAuth on-behalf-of flow (the JWT bearer grant) to reach an Azure Storage Account as the user and retrieve content scoped to that specific identity.

That single walkthrough exercises three of the most common patterns an architect will encounter: interactive user authentication, the client credentials flow for an app acting as itself, and on-behalf-of for carrying a user's identity context downstream. The promised payoff is seeing how the id tokens and access tokens actually differ across these scenarios, which claims appear where, and how they get consumed upstream.

Business impact

For anyone running a multi-cloud or hybrid estate, the strategic read is straightforward. Identity is becoming the integration layer between clouds, and Entra ID is the gatekeeper for any application or agent that needs to consume Azure or M365 resources, even when that workload lives in AWS, Google Cloud, or on-premises. The on-behalf-of flow in particular is what lets an agent act with a user's permissions rather than a broad standing service account, which has direct consequences for least-privilege design and audit.

The cost of misunderstanding the application object versus service principal split is usually paid in wasted migration time and over-provisioned permissions. Teams grant Graph permissions to the wrong object, or they assume a multi-tenant app needs a new registration per customer when it needs a new service principal instead. Those mistakes are cheap to avoid if the model is clear and expensive to unwind once an integration is in production.

The broader signal is that Microsoft is investing heavily in agent identity, and the new principal types are not cosmetic. Organizations evaluating where to build AI agents should weigh how each platform handles identity propagation, because the provider that makes delegated agent access auditable and revocable has a real advantage over one that leans on shared secrets. This first installment does not answer that comparison yet, but it lays the groundwork to evaluate it intelligently. Subsequent posts in the series will cover the frontend authentication and token inspection, the Graph API calls for nested group membership, and the full on-behalf-of flow through the backend API.