Thang Chung

Posted on Jul 27

Building Hybrid Authentication for Agentic Apps with Microsoft Entra ID and Microsoft Entra Agent ID

#webdev #ai #azure #dotnet

Introduction

When building applications with AI agents today, everything has changed. One of the most important areas to consider from the very beginning is authentication and authorization for AI agents.

Let me give you some context. In the past, we were all working with a static view of how authentication should be implemented for applications. In addition, everything executed inside an AI agent should be treated as untrusted, which is why it should run inside its own sandbox. From a security perspective, you should also apply the Principle of Least Privilege and Zero Trust Architecture (ZTA) whenever you delegate work to AI agents.

Over the past several months, I have been involved in designing AI-powered systems for multiple projects at my current company. One of the biggest challenges we consistently faced was how to build these systems securely while ensuring authentication and authorization are first-class concerns rather than afterthoughts.

If you have been following how MCP is evolving for enterprise applications, you have probably seen the introduction of Enterprise-Managed Authorization (EMA), which represents an SSO moment for MCP clients and servers. Along with EMA, the MCP ecosystem is introducing new standards and protocols such as ID-JAG, built on top of RFC 8693, RFC 7523, XAA, and others.

However, at our company, our technology stack is primarily built on Microsoft Azure and Microsoft Entra. Therefore, we decided to first explore how the Microsoft ecosystem addresses the authentication and authorization challenges of Agentic AI. This article focuses on that approach.

In future articles, I will also explore how ID-JAG (XAA) can be integrated with Microsoft Entra and how both approaches can work together in enterprise environments.

This article shows how to solve these authentication challenges by combining Microsoft Entra ID with the newly introduced Microsoft Entra Agent ID.

Disclaimer: For this article, I use Agent Gateway (v1.4.0-beta.1 at the time of writing) to configure and delegate the RFC 8693 / OAuth 2.0 Token Exchange (On-Behalf-Of) flow at the infrastructure layer. This is purely for experimentation and to demonstrate the authentication flow, rather than as a production recommendation.

Let's start with a simple scenario.

We have a Todo application that allows users to manage their todo list. To keep the example simple, assume there are only two operations:

Get all todo items
Add a new todo item: the human just needs to input the name of the todo; the description will be generated by the AI Agent

Let's focus on the Get All Todo Items flow first. There is nothing particularly special about the business logic. We set up three applications: todo-api, todo-agent, and todo-mcp, with the following configuration:

todo-api uses Microsoft Entra ID App Registration. This is the traditional authentication model that most of us have been using for years.
todo-agent uses Microsoft Entra Agent ID. This is Microsoft's new authentication model for agentic applications. Rather than replacing Microsoft Entra ID, it extends it by introducing new concepts such as Agent Blueprints and Agent Identities. If these concepts are new to you, I highly recommend reading https://blog.christianposta.com/entra-agent-id-agw/ before continuing with this article.
todo-mcp also uses Microsoft Entra ID App Registration, following the same configuration as todo-api.

As you can see, the solution uses a hybrid authentication model that combines traditional Microsoft Entra ID App Registrations with Microsoft Entra Agent ID for agentic applications.

The user accesses Todo API.
The application redirects the user to the Microsoft Entra ID sign-in page.
The user authenticates and grants consent using the OAuth 2.0 Authorization Code Flow with PKCE.
Todo API receives a JWT access token issued for the App Registration (TK01).
Todo API validates TK01 using Microsoft Entra ID.
Todo API performs an On-Behalf-Of (OBO) token exchange from TK01 (App Registration) to TK02 (Agentic Application).
Todo API forwards TK02 to todo-agent.
Todo Agent validates TK02 using Microsoft Entra Agent ID.
Todo Agent performs another token exchange from TK02 (Agentic Application) to TK03 (App Registration).
Todo Agent forwards TK03 to todo-mcp.
Todo MCP validates TK03 using Microsoft Entra ID.

Source code: agentgateway-entraid-obo

Note: Hop-1 and Hop-2 are fundamentally different token exchange mechanisms.

Hop-1 (TodoApi → TodoAgent) uses the standard RFC 7523 JWT Bearer On-Behalf-Of (OBO) flow. Agent Gateway's backendAuth.oauthTokenExchange supports this flow directly (grantType: jwtBearer), as confirmed in the Agent Gateway source code (https://github.com/agentgateway/agentgateway). The gateway performs the token exchange, keeping application code simple.

Hop-2 (TodoAgent → TodoMcpServer) is not a standard OBO flow. Microsoft Entra Agent ID uses a proprietary two-step fmi_path token exchange based on the client_credentials grant. The agent authenticates using its own Agent Blueprint credential (client secret or Federated Identity Credential) while simultaneously acting on behalf of the signed-in user. This exchange type does not exist in the current Agent Gateway configuration schema. The gateway only supports the standard jwtBearer exchange used in Hop-1. This is not a limitation of the configuration—it simply reflects the different protocol used by Microsoft Entra Agent ID.

Authentication - set up the hybrid authentication flow (Microsoft Entra ID + Microsoft Entra Agent ID) for todo-api, todo-agent, and todo-mcp

az login

Then run:

./scripts/setup-entra-obo-chain.ps1

That's it.

Start the solution by running:

aspire run

from the repository root.

Open up http://localhost:3000/scalar, and authenticate as follows:

It will let you input a username(Bob)/password (on the MS Entra ID page). After doing that, go back to http://localhost:3000/scalar. Now click to create a new todo; it will create 1 record in the db, go back to Aspire and show the trace:

And what the Todo agent does:

Some setup for todo-api, todo-agent, and todo-mcp

1.todo-api

2.todo-agent
- Agent BlueSprint

Agent Identity

3.todo-mcp

Authorization - set up security groups for todo-api, todo-agent, and todo-mcp

We create two Microsoft Entra security groups:

Super Admin, with Bob assigned.
Normal User, with Alice assigned.

The authorization requirements are straightforward:

When Bob signs in, he can call both MCP tools: Get All Todos and Create Todo.
When Alice signs in, she is authorised to call only the Get All Todos MCP tool.

The following screenshots show the configuration.

Bob wants to create a new todo item => because he has full permission, he can create it without any problem.

On the other hand, Alice does the same with Bob, but because she isn't assigned permission to create a new todo item, the system will prevent her from doing that and throw an exception.

Some of the Microsoft Entra configuration:

Azure Entra Groups:

After that, you have to assign the group claim for todo-api app:

Do the same with todo-mcp-server app.

With todo-agent agentic app, we need to use the az CLI, because right now there is no UI to set it up:

az rest --method PATCH \
    --uri "https://graph.microsoft.com/v1.0/applications(appId='<your todo agentic app id>')" \
    --headers "Content-Type=application/json" \
    --body '{"groupMembershipClaims":"SecurityGroup"}' 2>&1