> ## 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.

export const ReleaseStageNotice = ({feature, stage, plans, contact, terms}) => {
  const stageTextMap = {
    "beta": "bêta",
    "ea": "Accès anticipé"
  };
  const stageText = stageTextMap[stage] || "une phase de lancement du produit";
  const prsLink = "/docs/troubleshoot/product-lifecycle/product-release-stages";
  const linkify = (text, url) => {
    return <a href={url} target="_blank" rel="noreferrer" class="link">{text}</a>;
  };
  const includeDetails = (plans, contact, terms) => {
    const hasDetails = terms || plans || contact;
    if (!hasDetails) return null;
    return <span data-as="p">
            {plans && <>Cette fonctionnalité est offerte avec les forfaits {linkify(`${plans}`, "https://auth0.com/pricing")}. </>}
            {contact && "Pour y participer, communiquez avec " + contact + ". "}
            {terms && <>En utilisant cette fonctionnalité, vous acceptez les conditions applicables de l’essai gratuit énoncées dans le {linkify("Master Subscription Agreement", "https://www.okta.com/legal")} d’Okta.</>}
        </span>;
  };
  return <Warning>
            <span data-as="p">
                <strong>La fonctionnalité {feature} est en {linkify(stageText, prsLink)}.</strong>
            </span>

            {includeDetails(plans, contact, terms)}
        </Warning>;
};

<ReleaseStageNotice feature="Agent as Principal" stage="ea" contact="Auth0 Support" terms="true" />

Une fois l'agent [associé à un client](/docs/fr-ca/ai-agents-mcp/agent-as-principal/associate-agent-client), 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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Auth0 ne prend pas en charge le [type d'autorisation `jwt_bearer`](/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt) pour les clients liés à un agent.
</Callout>

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.

<h2 id="agent-subject-claims">
  Demandes personnalisées du sujet de l'agent
</h2>

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](/docs/fr-ca/secure/sender-constraining/demonstrating-proof-of-possession-dpop)) 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`.

<h2 id="configure-resource-server-to-receive-agent-subject-claims">
  Configurer le serveur de ressources pour recevoir les demandes de sujet de l'agent
</h2>

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"
}
```

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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.
</Callout>

<h2 id="standard-login-flow">
  Flux de connexion standard
</h2>

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"
  }
}
```

<h2 id="client-credentials-flow">
  Flux des identifiants client
</h2>

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
}
```

<h2 id="on-behalf-of-obo-token-exchange">
  Échange de jetons On-Behalf-Of (OBO)
</h2>

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](/docs/fr-ca/secure/call-apis-on-users-behalf/on-behalf-of-token-exchange). 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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](/docs/fr-ca/secure/call-apis-on-users-behalf/on-behalf-of-token-exchange).
</Callout>

<h2 id="next-steps">
  Prochaines étapes
</h2>

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