From OBO APIs to Agent Identities: Entra Conditional Access Still Works the Same

Source: Dev.to

Source: From OBO APIs to Agent Identities: Entra Conditional Access Still Works the Same – Dev.to

Introduction

Six years ago I wrote a small sample to help me better understand how the On‑Behalf‑Of (OBO) flow actually works—a browser SPA calling a middle‑tier Web API, which then called Azure SQL on behalf of the signed‑in user.

Today the same pattern might be an assistive AI agent calling an MCP server with the delegated constraints of the end‑user. The rules are unchanged. This article explains why.

Three sentences that should survive beyond any particular technology

1. If your system acts on behalf of a user, delegation rules apply.
2. If delegation rules apply, Conditional Access applies at token issuance for the downstream resource.
3. APIs, agents, and MCP servers don’t change that—they only change the shape of the middle tier.

If an AI agent acts on behalf of a user, your existing Conditional Access policies that govern how users access corporate data already apply—automatically. You don’t need to invent “agent‑specific Conditional Access” for assistive agents. Assistive agents don’t bypass Conditional Access; they inherit it.

If you understand OBO and Conditional Access from classic Web APIs, you already understand how Entra Agent ID behaves for assistive AI agents.
Delegation semantics didn’t change. Conditional Access behavior didn’t change. Only the shape of the middle tier changed.

1. The Classic Delegated Access Pattern

The baseline architecture is the standard delegated‑access chain:

User
  ↓
SPA (interactive client)
  ↓  access token  [aud = Web API]
Web API (confidential client)
  ↓  OBO token     [aud = Resource]
Azure SQL  |  MCP Server

Two facts to hold firmly

• The Web API never authenticates as itself to the downstream resource. It always acts on behalf of the signed‑in user.
• The downstream resource — Azure SQL, Microsoft Graph, or an MCP server — receives a delegated token. It evaluates the user’s identity and the delegated scopes. Conditional Access policies have already been enforced by Entra during token issuance.

2. The Web API Has a Real Identity — and Delegation Is Explicitly Granted

This detail is often omitted from diagrams, yet it matters in production.

• The Web API is not just “code that runs somewhere”. In Microsoft Entra it is a registered application with its own identity. That identity authenticates to the token endpoint as a confidential client, using a client secret or certificate.

In a real OBO implementation the Web API does two things simultaneously:

1. Authenticates as itself – proving “I am the Web API” using its own credentials.
2. Requests a delegated token for the downstream resource on behalf of the user, presenting the incoming user token as an assertion.

Important: The capability to perform OBO is not implicit. The Web API’s identity must be explicitly granted the delegated permissions (scopes) for the downstream resource. The tenant administrator grants this; the Web API cannot do it on its own authority.

Practical framing: the Web API authenticates as itself, but it can only mint delegated tokens because the tenant has explicitly authorized it to act on the user’s behalf for the specific downstream resource.

3. OBO in 90 Seconds

The flow has three steps:

1. User sign‑in – The user signs in to the client. The client receives an access token whose audience is the Web API and uses that token to call the Web API.
2. Token exchange – The Web API calls the token endpoint and exchanges the client token for a new one.
3. Downstream token – The resulting token is minted for the downstream resource; it carries the user’s identity from step 1 and the delegated scopes from step 2.

Protocol view

The exchange is performed with a single HTTP request that includes both client authentication (client_id + client_secret) and the user assertion (assertion). Both parts are required.

POST https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=<JWT_ASSERTION>
&requested_token_use=on_behalf_of
&scope=https://database.windows.net/.default
&client_id=<CLIENT_ID>
&client_secret=<CLIENT_SECRET>

Key invariant

• OBO is strictly delegated.
• It uses delegated scopes, not application roles.
• Application permissions are not involved.

4. Conditional Access – Who Is Targeted vs. Who “Feels” It

The real misunderstanding occurs here, and it only gets worse when agents are introduced.

Rule 1 – CA is assigned to the user and targets the resource

• A Conditional Access (CA) policy that requires MFA to access Azure SQL (or an MCP server) is scoped to the user and the downstream resource.
• Evaluation happens when Microsoft Entra issues the delegated token for that resource – i.e., at the moment the OBO token is minted.
• It does not happen when the user signs into the SPA, nor when the middle tier starts up.

Rule 2 – The middle tier is not a CA subject

• Even though the Web API has its own registered identity, it is not the subject of a CA policy that governs how users access corporate data.
• The CA policy constrains the user’s access, not the middle‑tier service identity.
• This holds true regardless of what the middle tier is (Web API, assistive AI agent, MCP server, etc.).

Rule 3 – The middle tier still experiences CA outcomes

• When the Web API calls the token endpoint to acquire an OBO token, CA enforcement occurs there.
• If the policy requires step‑up (e.g., MFA), the token endpoint returns interaction_required together with a claims challenge.
• The middle tier cannot satisfy this challenge itself; it must surface the challenge back to the interactive client (the SPA).
• The user completes the MFA, the client obtains a new token, and the middle tier retries the OBO exchange.

One‑liner: the middle tier is a CA messenger, not a CA subject.

End of document.

5. Replacing the Web API with an (Assistive) AI Agent (with an Agent Identity)

The transition to Entra Agent ID is explicit and mechanical:

Note: Nothing in the right‑hand column is new behavior.
When using Entra Agent ID in delegated mode (the appropriate mode for an assistive agent acting on behalf of a signed‑in user), three requirements apply:

1. Grant delegated permissions to the Agent Identity for the downstream resource.
2. The Agent Identity acquires a delegated token that represents the user, carrying the user’s identity and scopes.
3. The Agent Identity is constrained by Conditional Access (CA) policies that govern the user’s access to that resource.

Core continuity: you replace the middle‑tier actor, not the trust boundary.

6. MCP Server as the Downstream Resource

MCP servers can feel “agent‑native,” which may lead engineers to think the security model has changed around them. It hasn’t.

• MCP Server = OAuth‑protected resource – a server that accepts access tokens.
• Never pass tokens through. This rule applies both to:
  1. An AI agent acting on‑behalf‑of the user, and
  2. An MCP server requesting authorizations to other resources on‑behalf‑of the user.

Beyond that, whether the downstream resource is Azure SQL, Microsoft Graph, or any other service, the Conditional Access (CA) and delegation rules are identical. From Microsoft Entra’s perspective it is simply an OAuth‑protected resource:

• Tokens are issued for the resource.
• Delegated permissions are scoped to the resource.
• Conditional Access policies target the resource.

7. What to Actually Configure

1. Model your chain – Identify the downstream resource (REST API or MCP server) and the middle actor (Web API or agent identity in delegated mode).

2. Make delegation explicit – Confirm the middle actor is granted the delegated permissions required for the downstream resource.

3. Treat CA challenges as a product requirement – Expect interaction_required responses and claims challenges during downstream token acquisition.

   • In your agent’s backend, implement a handler for MsalUiRequiredException (or the equivalent).
   • Design the user‑interaction path to satisfy step‑up; do not swallow these errors.

4. Never pass tokens through – Validate the incoming token for the agent audience, then acquire a fresh token for any downstream resource.