---
title: Authentification unique
url: https://platform.claude.com/docs/fr/managed-agents/self-hosted/configure
description: Permettez aux personnes et aux services d'appeler votre serveur Claude Managed Agents auto-hébergé avec des jetons émis par votre fournisseur d'identité.
---

<Note>
  Pour demander l’accès à Claude Managed Agents auto-hébergé, contactez l’équipe de votre compte Anthropic.
</Note>

Par défaut, votre serveur accepte une clé partagée unique, la [clé API du serveur](https://platform.claude.com/docs/fr/managed-agents/self-hosted#the-three-credentials). Avec le « single sign-on » (authentification unique), chaque personne ou service peut également appeler le serveur avec un jeton émis par votre fournisseur d’identité OpenID Connect (OIDC). Le serveur attribue un rôle à l’appelant à partir des groupes présents dans le jeton. La clé API du serveur continue de fonctionner comme identifiant d’administrateur.

Cette page explique comment ajouter votre fournisseur d’identité, ce que chaque rôle peut faire et comment permettre aux développeurs de se connecter depuis un terminal.

## Ajouter votre fournisseur d’identité

<Steps>
  <Step title="Enregistrer le serveur dans votre fournisseur d’identité">
    Enregistrez le serveur comme API avec un identifiant tel que `api://cma-server`, et faites en sorte que les clients demandent des jetons pour celle-ci.
  </Step>

  <Step title="Lister le fournisseur d’identité dans le fichier de paramètres">
    Ajoutez une entrée sous `auth.issuers` dans le [fichier de paramètres](https://platform.claude.com/docs/fr/managed-agents/self-hosted/configuration-reference#where-settings-go) :

    ```yaml
    auth:
      issuers:
        - name: okta
          issuer_url: https://login.example.com/oauth2/default
          audiences: [api://cma-server]
          roles:
            - group: cma-admins
              role: admin
            - group: "eng-*"
              role: developer
    ```

    * `name` identifie l’émetteur dans les lignes de journal, et le serveur l’enregistre comme partie du créateur de chaque ressource. Ne le modifiez pas une fois que des personnes ont créé des ressources.
    * `issuer_url` doit être égal à la revendication `iss` de vos jetons.
    * `audiences` liste les valeurs que la revendication `aud` d’un jeton peut contenir, comme l’identifiant de la première étape.
    * `roles` mappe un groupe vers `admin`, `developer` ou `user`. Le rôle le plus élevé parmi les correspondances l’emporte.

    Pour les autres champs, consultez [Entrées d’émetteur](https://platform.claude.com/docs/fr/managed-agents/self-hosted/configuration-reference#issuer-entries). Si votre fournisseur est Microsoft Entra ID, consultez également [Microsoft Entra ID](https://platform.claude.com/docs/fr/managed-agents/self-hosted/configure#microsoft-entra-id).
  </Step>

  <Step title="Redémarrer le serveur et vérifier la connexion">
    Redémarrez le serveur. Un appelant envoie le jeton sous la forme `Authorization: Bearer <token>`, sur toute route qui accepte la clé API du serveur.

    Pour chaque requête authentifiée par un jeton, le serveur journalise `auth=oidc`, le `name` de l’émetteur et le sujet de l’appelant (`sub=`).
  </Step>
</Steps>

### Si la connexion échoue

| Réponse                                        | Cause                                                                        | La ligne de journal du serveur contient |
| ---------------------------------------------- | ---------------------------------------------------------------------------- | --------------------------------------- |
| `401`, identique à celle d’une clé API erronée | Le jeton a échoué à une vérification. La ligne de journal indique la raison. | `oidc token`                            |
| `403`                                          | Les groupes du jeton ne correspondent à aucune entrée `roles`                | `token holds no role`                   |

### Microsoft Entra ID

Entra ID diffère des autres fournisseurs sur deux points. Les deux paramètres se placent dans l’entrée de l’émetteur :

* **La personne :** Entra ID attribue à une personne un `sub` différent dans chaque application cliente ; la valeur par défaut enregistrerait donc une même personne comme plusieurs créateurs. Définissez `subject_claim: oid`.
* **Les groupes :** Entra ID omet la revendication `groups` d’un jeton si la personne appartient à de nombreux groupes. Cette personne ne correspond alors à aucune entrée `roles`. Pour éviter cela, faites en sorte qu’Entra ID n’émette que les groupes attribués à l’application. Ou bien attribuez des rôles d’application aux personnes dans Entra ID, et définissez `groups_claim: roles` afin que le serveur lise les rôles d’application à la place des groupes.

## Ce que chaque rôle peut faire

| Rôle                              | Agents, skills, sessions, coffres-forts et magasins de mémoire | Environnements                                            |
| --------------------------------- | -------------------------------------------------------------- | --------------------------------------------------------- |
| `admin`, et la clé API du serveur | Voit et modifie tout                                           | Les crée, les modifie et les supprime, et crée leurs clés |
| `developer` ou `user`             | Voit et modifie uniquement ce que cet appelant a créé          | Les liste, les lit et y exécute des sessions              |

`developer` et `user` disposent du même accès. Un appelant disposant de l’un ou l’autre rôle :

* **Ne peut pas voir une ressource créée par quelqu’un d’autre.** La ressource est absente des listes, et une requête pour son ID reçoit la même réponse qu’une requête pour un ID inconnu. Cela inclut tout ce qui a été créé avec la clé API du serveur avant que vous n’activiez l’authentification unique.
* **Ne peut pas partager une ressource** avec un autre appelant ou un groupe.

Mappez `admin` vers des noms de groupes exacts. Un administrateur peut aussi démarrer une session qui utilise le coffre-fort de n’importe quel utilisateur. N’attribuez donc ce rôle qu’à des groupes auxquels vous confiez les jetons MCP de tous les utilisateurs.

## Permettre aux développeurs de se connecter depuis un terminal

Les développeurs peuvent se connecter via votre fournisseur d’identité, puis utiliser la CLI `ant` sous leur propre identité, sans la clé API du serveur. Vous effectuez les deux premières étapes, et chaque développeur effectue la troisième.

<Steps>
  <Step title="Enregistrer une application dans votre fournisseur d’identité">
    Enregistrez une application native (« publique ») qui dispose des éléments suivants :

    * Aucun secret client
    * Le flux d’octroi par code d’autorisation avec PKCE
    * L’URI de redirection `http://127.0.0.1/callback`

    Certains fournisseurs nécessitent l’une des [autres URI de redirection](https://platform.claude.com/docs/fr/managed-agents/self-hosted/configure#other-redirect-uris).
  </Step>

  <Step title="Ajouter l’application à l’entrée de l’émetteur">
    Ajoutez `login_client_id` et `login_scopes` à l’entrée de l’émetteur, puis redémarrez le serveur :

    ```yaml
    login_client_id: 0oa1b2c3d4e5f6g7h8i9
    login_scopes: [openid, cma-server.access]
    ```

    `login_scopes` liste les scopes dont votre fournisseur a besoin pour émettre un jeton dont la revendication `aud` figure dans la liste `audiences` de l’entrée de l’émetteur.
  </Step>

  <Step title="Se connecter">
    Chaque développeur exécute la connexion depuis la racine de l’archive extraite :

    ```bash
    ./cma-server-admin login https://cma.example.com
    ```

    L’URL du serveur doit commencer par `https://`, ou par `http://` vers `localhost`, `127.0.0.1` ou `::1`. Avec l’une des [autres URI de redirection](https://platform.claude.com/docs/fr/managed-agents/self-hosted/configure#other-redirect-uris), ajoutez son option à la commande.

    La commande ouvre la page de connexion du fournisseur dans un navigateur, puis écrit un profil de la CLI `ant` nommé `cma-server`. Passez `--profile cma-server` à n’importe quelle commande `ant`, ou exécutez `ant profile activate cma-server` pour faire de ce profil le profil par défaut.
  </Step>
</Steps>

Lorsque le jeton expire, le développeur exécute à nouveau `login`. Pour que la CLI `ant` renouvelle plutôt le jeton, ajoutez `offline_access` à `login_scopes`.

### Autres URI de redirection

| Fournisseur                                                | URI de redirection à enregistrer                                  | Option que les développeurs ajoutent à la commande `login` |
| ---------------------------------------------------------- | ----------------------------------------------------------------- | ---------------------------------------------------------- |
| Microsoft Entra ID                                         | `http://localhost/callback`                                       | `-listen localhost:0`                                      |
| Un fournisseur qui exige le port dans l’URI de redirection | Une URI avec un port fixe, comme `http://127.0.0.1:8123/callback` | `-listen 127.0.0.1:8123`                                   |

Pour lister les autres options, ajoutez `-h` à la commande `login`.

## Permettre aux utilisateurs de se connecter à la console de votre serveur

La console de votre serveur connecte les utilisateurs via l’application que vous avez enregistrée pour la [connexion depuis le terminal](https://platform.claude.com/docs/fr/managed-agents/self-hosted/configure#let-developers-log-in-from-a-terminal). Pour terminer sa configuration, consultez [Configurer la connexion](https://platform.claude.com/docs/fr/managed-agents/self-hosted/console#set-up-sign-in).