How the broker gets an Entra token for an agent

Описание и применение

Брокер получает токен Entra для агента, используя три шага: обновление, T1 с fmi_path и OBO, чтобы получить токен Graph с нужными утверждениями, избегая общего секрета и обеспечивая аудит.

Задача

The broker must issue an Azure Entra token that Graph accepts for a specific user acting through a specific AI agent, without sharing a single client secret across all agents.

Результат

The broker can now issue per‑agent Graph tokens that preserve auditability (azp and oid) and avoid shared secrets, enabling fine‑grained revocation and secure credential handling.

Рабочий процесс

• 1. Refresh: broker retrieves user refresh token from vault and redeems it with Entra.
• 2. T1: broker requests a token naming the agent blueprint and identity; Entra returns a token with fmi_path indicating the agent identity.
• 3. OBO: broker performs on‑behalf‑of exchange using the T1 token to obtain a Graph access token with the required scopes.

Доказательства

The broker has to produce an Entra token that Graph or another API will accept, for the right user, acting through the right agent.

Источник

Getting a Graph token for an agent takes three steps. The broker runs them in order, and each one has its own failure modes.

Источник

The broker performs an on‑behalf‑of exchange, presenting the T1 token. The result is an access token whose audience is Graph and whose scopes are the ones the resource map allowed.

Источник

The broker checks on the final token. These are the properties we assert in the end‑to‑end test: aud = https://graph.microsoft.com scp = User.Read azp = <the agent identity id> oid = <the user's object id>

Источник

A client secret would make the broker look like a single application, and every agent would share its rights.

Источник