> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.

# L'identité de l'agent dans les jetons

> Comment Auth0 intègre l'identité de l'agent dans les jetons d'accès, que ce soit dans les flux d'informations d'identification du client, d'échange de jetons OBO ou de connexion standard.

> [!WARNING]
>
> **La fonctionnalité Agent as Principal est en .**

Une fois l'agent [associé à un client](https://auth0.com/docs/fr-ca/ai-agents-mcp/agent-as-principal/associate-agent-client.md), les jetons émis à ce client portent l'identité de l'agent à des fins d'attribution et de traçabilité. La façon dont l'identité de l'agent apparaît dans le jeton dépend du type d'autorisation :

* [Flux des identifiants client](#client-credentials-flow) : l'agent est le sujet. Son identité apparaît dans la demande personnalisée `sub` de premier niveau.
* [Flux de connexion standard](#standard-login-flow) : l'utilisateur est le sujet. L'identité de l'agent apparaît dans une demande personnalisée `act` à un seul niveau.
* [Échange de jetons On-Behalf-Of (OBO)](#on-behalf-of-obo-token-exchange) : l'utilisateur demeure le sujet. L'identité de l'agent apparaît dans la demande personnalisée `act`, accompagnée d'une demande personnalisée `act` imbriquée qui indique le client d'origine.

Auth0 ne prend pas en charge le [type d'autorisation `jwt_bearer`](https://auth0.com/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt) pour les clients liés à un agent.

Auth0 adopte également l'ébauche [OAuth Actor Profile for Delegation](https://www.ietf.org/archive/id/draft-mcguinness-oauth-actor-profile-00.html), qui introduit les demandes personnalisées `sub_profile` et `client_profile` afin d'identifier explicitement le type d'entité à chaque position du jeton.

## Demandes personnalisées du sujet de l'agent

Les demandes personnalisées `sub_profile` et `client_profile` précisent le type d'entité dans les jetons émis par les clients liés à un agent :

| Demande personnalisée | Description |
| - | - |
| `sub_profile` | Type d'entité du sujet. Valeurs : `user`, `ai_agent`, `service`, `browser_app`, `native_app`. |
| `client_profile` | Type d'entité du client demandeur. Valeurs : `user`, `ai_agent`, `service`, `browser_app`, `native_app`. Plusieurs valeurs séparées par une espace sont permises (par exemple, `service ai_agent`). |
| `act` | Demande personnalisée d'acteur pour l'échange de jetons OBO. Présente dès qu'un client lié à un agent intervient. Contient `sub`, `iss`, `sub_profile`, `client_id`, `client_profile` et, facultativement, `cnf` ([liaison DPoP](https://auth0.com/docs/fr-ca/secure/sender-constraining/demonstrating-proof-of-possession-dpop.md)) ainsi qu'une demande personnalisée `act` imbriquée pour les chaînes à sauts multiples. |

Vous devez [configurer votre serveur de ressources](#configure-resource-server-to-receive-agent-subject-claims) pour qu'il reçoive les demandes personnalisées `sub_profile` et `client_profile` dans les jetons émis. Partout où l'identifiant d'un agent apparaît dans une demande personnalisée (`sub` de premier niveau ou `act.sub`), il s'agit de l'`external_agent_id` de l'agent si celui-ci a été défini à la création; sinon, il s'agit de l'`agent_id`.

## Configurer le serveur de ressources pour recevoir les demandes de sujet de l'agent

Pour recevoir les demandes `sub_profile` et `client_profile`, définissez `agent_subject_claims: 'auth0-v1'` sur le serveur de ressources cible. Cette option doit être activée individuellement pour chaque serveur de ressources.

```http theme={null}
PATCH /api/v2/resource-servers/{id}
Content-Type: application/json

{
  "agent_subject_claims": "auth0-v1"
}
```

La demande personnalisée `sub_profile` introduit un type d'entité formel dans le jeton. Les services qui reçoivent des jetons ne devraient pas présumer que `sub_profile` vaudra toujours user. Si `sub_profile` est absent (l'option n'est pas activée pour le serveur de ressources), le comportement actuel demeure inchangé.

Vérifiez la façon dont `sub` est analysé dans les services en aval avant d'activer l'option. Les services qui valident ou analysent le format de la demande personnalisée `sub` devront peut-être être mis à jour pour traiter `ai_agent` comme un type d'entité valide dans le cas des octrois par information d'identification du client.

## Flux de connexion standard

Un client lié à un agent peut exécuter un flux de connexion standard à l'aide de l'octroi par code d'autorisation, implicite, CIBA, par appareil, MFA, par mot de passe, par clé d'identification ou par jeton d'actualisation. Le sujet demeure l'utilisateur. L'identité de l'agent n'apparaît pas dans la demande personnalisée `sub` de premier niveau. À la place, une demande personnalisée `act` à un seul niveau est ajoutée afin que l'agent puisse être identifié dans le jeton.

Dans l'exemple suivant, un client lié à un agent exécute un flux de connexion standard et émet un jeton comportant les demandes de sujet d'agent suivantes :

* `sub` : l'identifiant de l'utilisateur
* `sub_profile` : `user`
* `client_profile` : `ai_agent`, qui indique que le client est lié à un agent
* `act` : une demande d'acteur à un seul niveau qui identifie l'agent (`"sub": "agt_1a2b3c", "sub_profile": "ai_agent"`)

```json theme={null}
{
  "iss": "https://YOUR_AUTH0_DOMAIN/",
  "sub": "auth0|user123",
  "sub_profile": "user",
  "client_id": "agent-linked-client-id",
  "client_profile": "ai_agent",
  "aud": "https://resource-api.example.com",
  "scope": "read:data",
  "exp": 1711820400,
  "iat": 1711816800,
  "act": {
    "sub": "agt_1a2b3c",
    "sub_profile": "ai_agent",
    "client_id": "agent-linked-client-id"
  }
}
```

## Flux des identifiants client

Un client de communication entre machines (M2M) lié à un agent exécute un flux des identifiants client. L'agent est le sujet et s'authentifie en son propre nom; aucun utilisateur n'intervient.

Dans l'exemple suivant, un client M2M lié à un agent exécute un flux des identifiants client et émet un jeton comportant les demandes de sujet d'agent suivantes :

* `sub` : l'`external_agent_id` de l'agent s'il en a été défini un à la création, sinon l'`agent_id`
* `sub_profile` : `ai_agent`
* `client_profile` : `service ai_agent`, représentant le client M2M lié à l'agent

```json theme={null}
{
  "iss": "https://YOUR_AUTH0_DOMAIN/",
  "sub": "agt_1a2b3c",
  "sub_profile": "ai_agent",
  "client_id": "YOUR_CLIENT_ID",
  "client_profile": "service ai_agent",
  "aud": "https://your-resource-api.example.com",
  "scope": "read:data",
  "exp": 1711820400,
  "iat": 1711816800
}
```

## Échange de jetons On-Behalf-Of (OBO)

Dans l'échange de jetons OBO, un utilisateur s'authentifie et reçoit un jeton d'accès dont le public est le serveur de ressources de l'agent. Le client lié à l'agent échange ensuite ce jeton contre un jeton délégué au moyen de l'[échange de jetons On-Behalf-Of](https://auth0.com/docs/fr-ca/secure/call-apis-on-users-behalf/on-behalf-of-token-exchange.md). L'utilisateur demeure le sujet tout au long du processus. L'agent est identifié comme l'acteur dans la demande personnalisée `act`.

Avant l'échange de jetons, l'utilisateur s'authentifie au moyen d'une application de navigateur et reçoit un jeton d'accès :

* `sub` : l'identifiant de l'utilisateur
* `sub_profile` : `user`
* `client_profile` : identifie le client d'origine comme un `browser_app`
* `aud` : le serveur de ressources de l'agent

```json theme={null}
{
  "iss": "https://YOUR_AUTH0_DOMAIN/",
  "sub": "auth0|user123",
  "sub_profile": "user",
  "client_id": "spa-client-id",
  "client_profile": "browser_app",
  "aud": "https://ai-agent-resource-server.example.com",
  "scope": "read:data",
  "exp": 1711820300,
  "iat": 1711816700
}
```

Le client lié à l'agent échange le jeton de l'utilisateur au moyen de l'échange de jetons OBO :

* `sub` : l'identifiant de l'utilisateur (inchangé)
* `sub_profile` : `user` (inchangé)
* `client_profile` : `service ai_agent`, qui représente le client lié à l'agent
* `aud` : le nouveau serveur de ressources
* `act` : l'acteur immédiat est l'agent, avec un `act` imbriqué qui indique le client d'origine ayant amorcé le flux. La profondeur maximale de délégation est de 5 sauts, soit 4 niveaux de `act` imbriqués.

```json theme={null}
{
  "iss": "https://YOUR_AUTH0_DOMAIN/",
  "sub": "auth0|user123",
  "sub_profile": "user",
  "client_id": "agent-client-id",
  "client_profile": "service ai_agent",
  "aud": "https://resource-api.example.com",
  "scope": "read:data",
  "cnf": { "jkt": "NzbLsXh8uDCcd7MNwrnNZpX0ak8ACQ" },
  "exp": 1711820400,
  "iat": 1711816800,
  "act": {
    "sub": "agt_1a2b3c",
    "sub_profile": "ai_agent",
    "client_id": "agent-client-id",
    "act": {
      "sub": "spa-client-id",
      "sub_profile": "browser_app",
      "client_id": "spa-client-id"
    }
  }
}
```

L'échange de jetons prend actuellement en charge l'OBO uniquement lorsque le sujet du jeton entrant est un utilisateur. L'émission de jetons dans lesquels un agent ou un client est lui-même le sujet de premier niveau d'un échange OBO n'est pas encore prise en charge.

Les jetons d'actualisation ne sont pas pris en charge pour l'échange de jetons OBO. Pour en apprendre davantage sur la configuration et les limites, faites la lecture de [Échange de jetons On-Behalf-Of](https://auth0.com/docs/fr-ca/secure/call-apis-on-users-behalf/on-behalf-of-token-exchange.md).

## Prochaines étapes

* Ajoutez du [contexte d'agent aux jetons d'accès à l'aide des Actions](https://auth0.com/docs/fr-ca/ai-agents-mcp/agent-as-principal/actions-context.md)
* Interrogez l'[ID de l'agent dans les journaux du locataire](https://auth0.com/docs/fr-ca/ai-agents-mcp/agent-as-principal/tenant-logs.md) pour assurer l'attribution et la traçabilité de l'identité de l'agent