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

# Enregistrement par document de métadonnées de l’identifiant du client (CIMD)

> Apprenez-en davantage sur l’enregistrement par document de métadonnées de l’identifiant du client (CIMD) dans Auth0, notamment sur ses avantages, ses cas d’utilisation et le fonctionnement du CIMD manuel et dynamique.

> [!WARNING]
>
> **La fonctionnalité Dynamic CIMD Registration est en .**

Enregistrez une application dans Auth0 en important, à partir d’une URL, un document de métadonnées d’identifiant du client (CIMD) hébergé à l’externe. Un CIMD est un fichier JSON hébergé sur votre domaine qui contient des métadonnées du client (p. ex., `https://example-client.com/mcp-metadata.json`). L’URL du CIMD sert d’identifiant du client de l’application et prouve la propriété du domaine, ce qui garantit que seules des applications de confiance peuvent être enregistrées dans Auth0. Même si Auth0 conserve un registre de ces paramètres, le CIMD hébergé demeure la source de référence.

Auth0 prend en charge l’enregistrement manuel CIMD et l’enregistrement CIMD dynamique :

* Enregistrement manuel CIMD : importez manuellement une application à partir de l’URL de son CIMD. Auth0 récupère et valide le CIMD pour enregistrer l’application en tant que client CIMD; les mises à jour des métadonnées sont synchronisées au moyen d’actualisations manuelles.
* Enregistrement CIMD dynamique : l’application s’enregistre elle-même au moyen de l’URL de son CIMD lors de l’exécution, lorsqu’elle envoie une requête OAuth à Auth0; les mises à jour des métadonnées sont synchronisées de façon réactive, à la demande, lors des requêtes d’autorisation.

Seules les [applications tierces](/docs/fr-ca/get-started/applications/third-party-applications) peuvent être enregistrées avec CIMD; elles sont assujetties à des [mesures de sécurité renforcées](/docs/fr-ca/get-started/applications/third-party-applications/security-controls.md). Pour en savoir plus, consultez [Enregistrer des applications avec CIMD](/docs/fr-ca/get-started/auth0-overview/create-applications/register-applications-with-cimd.md).

Pour les clients CIMD enregistrés dynamiquement, les administrateurs de locataire peuvent utiliser les [profils d’application](/docs/fr-ca/get-started/applications/application-profiles.md) afin d’appliquer des paramètres d’application uniformes, notamment pour la durée de vie des jetons d’actualisation et le comportement des Organisations.

Les clients CIMD s’enregistrent toujours avec `third_party_security_mode: "strict"`, peu importe la valeur du paramètre **Create Permissive Third-Party Clients by Default** de votre locataire. Le mode permissif n’est pas offert pour les clients CIMD. Les applications tierces strictes [ne prennent pas en charge les Règles](/docs/fr-ca/get-started/applications/third-party-applications/security-controls.md#features-not-supported), et les parcours de connexion des clients CIMD échouent si des Règles sont actives dans votre locataire. Si vous utilisez des Règles, [migrez vers les Actions](/docs/fr-ca/customize/actions/migrate/migrate-from-rules-to-actions.md) avant d’enregistrer des clients CIMD.

Une fois enregistré, un client CIMD ne peut pas passer du mode manuel au mode dynamique, ni l’inverse. Pour changer de mode, supprimez le client et enregistrez-le de nouveau.

## Principaux avantages

L’enregistrement CIMD offre les avantages suivants :

1. Les clients MCP n’ont besoin d’être enregistrés avec CIMD qu’une seule fois par déploiement. Toutes les instances de ce déploiement utilisent les mêmes informations d’identification d’enregistrement.
2. L’enregistrement repose sur la cryptographie asymétrique (clés publiques/privées) plutôt que sur des secrets symétriques partagés, qui risquent d’être divulgués.
3. Les propriétaires d’applications gèrent les métadonnées du client directement dans le CIMD; lors de l’enregistrement, Auth0 associe automatiquement ces propriétés à sa configuration interne.
4. L’URL du CIMD sert d’identifiant lisible par un humain dans les journaux d’audit, ce qui permet de vérifier facilement l’origine des requêtes provenant de serveurs d’outils ou d’hôtes MCP précis.

## Cas d’utilisation

Voici quelques cas d’utilisation courants de l’enregistrement CIMD :

* Clients MCP : ils n’ont besoin d’être enregistrés avec CIMD qu’une seule fois par déploiement. Toutes les instances de ce déploiement utilisent les mêmes informations d’identification d’enregistrement. Pour découvrir comment Auth0 sécurise les clients et les serveurs MCP, consultez [Auth for MCP](/ai/docs/fr-ca/mcp/overview.md).
* Intégrations tierces : applications partenaires, plateformes SaaS et services externes qui authentifient les utilisateurs pour le compte d’organisations. Ces applications gèrent leurs propres métadonnées du client et clés cryptographiques, ce qui permet d’effectuer des mises à jour de façon autonome et de procéder à la rotation des clés sans avoir à partager de secrets.

## Exemple de CIMD

Voici un exemple de CIMD pour un client MCP public, où `"token_endpoint_auth_method": "none"` :

```json https://example-client.com/mcp-metadata.json wrap lines theme={null}
{
  "client_id": "https://example-client.com/mcp-metadata.json",
  "client_name": "Example MCP Tool Server",
  "description": "MCP server providing tools for data analysis",
  "logo_uri": "https://example-client.com/logo.png",
  "application_type": "web",
  "grant_types": ["authorization_code", "refresh_token"],
  "redirect_uris": [
    "https://example-client.com/callback"
  ],
  "token_endpoint_auth_method": "none",
  "response_types": ["code"]
}
```

Auth0 [associe et valide automatiquement les champs CIMD](/docs/fr-ca/get-started/auth0-overview/create-applications/cimd-validation-rules.md#cimd-json-validation-rules). Pour en apprendre davantage sur les types de clients pris en charge, consultez la section [Informations requises](/docs/fr-ca/get-started/auth0-overview/create-applications/register-applications-with-cimd.md#prerequisites).

## Enregistrement CIMD manuel ou dynamique

Le tableau suivant compare l’enregistrement manuel CIMD et l’enregistrement CIMD dynamique :

| Fonctionnalité | Enregistrement manuel CIMD | Enregistrement CIMD dynamique |
| - | - | - |
| **Identifiant du client** | URL HTTPS (p. ex., `https://yourdomain.com/client.json`) | URL HTTPS (p. ex., `https://yourdomain.com/client.json`) |
| **Authentification** | Clés asymétriques uniquement (aucun secret) | Clés asymétriques uniquement (aucun secret) |
| **Vérification de l’identité** | Propriété du domaine attestée par l’hébergement HTTPS | Propriété du domaine attestée par l’hébergement HTTPS |
| **Déclencheur de l’enregistrement** | L’administrateur du locataire importe l’application à partir de son URL CIMD | L’application s’enregistre d’elle-même à l’exécution, lors de sa première requête OAuth |
| **Gestion des métadonnées** | Le CIMD fait foi; actualisation manuelle | Le CIMD fait foi; actualisation automatique (de façon réactive et en arrière-plan) |
| **Examen des modifications de métadonnées par l’administrateur** | L’administrateur examine et approuve les modifications avant qu’elles s’appliquent | Aucun examen par l’administrateur; les modifications validées s’appliquent automatiquement |
| **Rotation des clés** | Plusieurs clés prises en charge dans `jwks_uri`; actualisation manuelle | Plusieurs clés prises en charge dans `jwks_uri`; résolution automatique au besoin |
| **Type d’application** | Applications tierces uniquement | Applications tierces uniquement |
| **Cas d’utilisation courants** | Clients MCP, intégrations tierces | Clients éphémères ou à volume élevé, comme les agents d’IA, qui s’enregistrent sans fourniture manuelle |

## Limite de clients CIMD dynamiques

Chaque locataire peut avoir au maximum 500 clients CIMD enregistrés dynamiquement. Seuls les clients que les applications ont enregistrés elles-mêmes au moment de l’exécution sont pris en compte dans cette limite, contrairement aux clients CIMD importés manuellement par un administrateur du locataire.

Les clients CIMD enregistrés dynamiquement sont aussi comptabilisés dans la [limite d’entités Applications](/docs/fr-ca/troubleshoot/customer-support/operational-policies/entity-limit-policy.md#enterprise) totale de votre locataire; chacun occupe donc une place dans les deux décomptes.

La limite de clients CIMD dynamiques peut être ajustée locataire par locataire. Pour demander une limite différente, communiquez avec [Auth0 Support](https://support.auth0.com/).

## Fonctionnement

Apprenez comment fonctionne l’enregistrement CIMD dans Auth0 :

**Enregistrement manuel CIMD**

Le diagramme suivant illustre le flux de bout en bout de l'enregistrement manuel CIMD :

* [Phase 1 : Enregistrement](#phase-1-registration)
* [Phase 2 : Autorisation](#phase-2-authorization)

```mermaid theme={null}
%%{init: { "sequence": { "mirrorActors": true }}}%%
sequenceDiagram
    rect rgb(240, 248, 255)
    Note over Tenant Admin,Auth0: Registration Phase
    participant Tenant Admin
    participant Auth0
    participant Domain
    Tenant Admin->>Auth0: Create CIMD app
    Auth0->>Tenant Admin: POST /register<br/>(external_client_id = https://.../client.json)
    Auth0->>Domain: GET https://.../client.json
    Domain-->>Auth0: Client metadata (CIMD JSON)
    Auth0->>Auth0: Validate + store client
    end
    rect rgb(240, 255, 240)
    Note over Client,Auth0: Authorization Phase
    actor User
    participant Client
    participant Auth0
    User->>Client: User-initiated task
    Client->>Auth0: /authorize?client_id = https://.../client.json<br/>(Auth0 resolves client by external_client_id == client_id)
    Auth0->>User: Consent screen<br/>(client metadata)
    User->>Auth0: Approve
    Auth0-->>Client: Authorization code
    Client->>Auth0: Exchange code
    Auth0->>Client: Complete authorization & redirect to client redirect_uri
    Client->>Auth0: Request resource access token with /oauth/token
    Auth0-->>Client: Return resource access token<br/>(includes client_id=https://../client.json)
    end
```

### Phase 1 : Enregistrement

Lors de l’enregistrement manuel CIMD, un administrateur du locataire enregistre l’application en important dans Auth0 son CIMD hébergé à l’externe :

1. **Création de l’application** : l’administrateur du locataire crée une application CIMD dans Auth0 de l’une des façons suivantes :
   * En sélectionnant **Import from URL** dans Auth0 Dashboard
   * En effectuant une requête `POST `au terminal `/register`, en fournissant l’`external_client_id`
2. **Récupération des métadonnées** : Auth0 effectue une requête `GET` vers le domaine du client pour récupérer le CIMD (client.json).
3. **Validation de sécurité** : Auth0 associe et valide l’URL du CIMD selon les [règles de validation des URL CIMD](/docs/fr-ca/get-started/auth0-overview/create-applications/cimd-validation-rules.md#cimd-url-validation-rules), et le CIMD selon les [règles de validation CIMD](/docs/fr-ca/get-started/auth0-overview/create-applications/cimd-validation-rules.md#cimd-json-validation-rules); il vérifie notamment que l’`external_client_id` correspond à l’URL du CIMD.
4. **Persistance** : une fois la validation réussie, Auth0 stocke les métadonnées du client dans la base de données.
5. **Confirmation** : Auth0 renvoie une réponse de réussite; l’application est désormais enregistrée comme client CIMD dans Auth0.

### Phase 2 : Autorisation

Une fois enregistrée, l’application utilise l’URL de son CIMD comme identité pendant le flux OAuth.

1. **Tâche lancée par l’utilisateur** : l’utilisateur lance une tâche pour laquelle l’application doit accéder à une API.
2. **Requête d’autorisation** : l’application envoie une requête au serveur d’autorisation Auth0 en transmettant l’URL de son CIMD comme `client_id`.
3. **Résolution du client** : le serveur d’autorisation Auth0 interroge la base de données pour faire correspondre l’URL fournie (`client_id`) à la configuration du client stockée (`external_client_id`).
4. **Consentement de l’utilisateur** : Auth0 présente à l’utilisateur un écran de consentement qui identifie l’application par le `client_name` tiré des métadonnées du CIMD.
5. **Redirection** : une fois que l’utilisateur a donné son consentement, Auth0 le redirige vers l’application avec un code d’autorisation.
6. **Échange du code** : l’application échange le code d’autorisation contre un jeton d’accès auprès du point de terminaison de jetons.
7. **Autorisation terminée** : le serveur d’autorisation Auth0 renvoie un jeton d’accès dont le `client_id` correspond à l’URL du CIMD. L’application peut maintenant accéder à l’API au nom de l’utilisateur.

**Enregistrement CIMD dynamique**

Le diagramme suivant illustre le flux de bout en bout de l'enregistrement CIMD dynamique :

```mermaid theme={null}
sequenceDiagram
      actor User
      participant CA as Client App
      participant AS as Authorization Server
      participant CD as Client's Domain (Hosts JSON)

      User->>CA: 1. Start Login
      CA->>AS: 2. Auth Request (client_id=https://...)

      alt Metadata Cached and Fresh
          AS->>AS: 3. Retrieve Cached Metadata
      else Metadata Missing or Stale
          AS->>CD: 3. GET /.../client-metadata.json
          CD-->>AS: 4. Returns client-metadata.json
          AS->>AS: 5. Validate Metadata (SSRF checks, etc.)
          AS->>AS: Create Non-Validated Client Record
      end

      AS->>User: 6. Show Consent Screen (using client_name)
      User->>AS: 7. Approve Consent
      AS-->>CA: 8. Redirect with Authorization Code

      CA->>AS: 9. Request Token (with Code)
      AS-->>CA: 10. Return Access Token
```

Lors de l’enregistrement CIMD dynamique, l’application s’enregistre elle-même auprès d’Auth0 au moment de l’exécution, sans étape d’enregistrement manuel préalable :

1. **Lancement de la connexion** : l’utilisateur lance une connexion à partir de l’application client.
2. **Requête d’autorisation** : l’application envoie une requête d’autorisation au serveur d’autorisation Auth0 en transmettant son URL CIMD comme `client_id`.
3. **Résolution des métadonnées** : si Auth0 dispose déjà de métadonnées récentes en cache pour le client, il utilise la copie en cache et passe les étapes suivantes. Sinon, Auth0 envoie une requête `GET` au domaine du client pour récupérer le CIMD (`client-metadata.json`).
4. **Retour des métadonnées** : le domaine du client renvoie le CIMD.
5. **Validation de sécurité** : Auth0 valide le CIMD selon les [règles de validation d’URL CIMD](/docs/fr-ca/get-started/auth0-overview/create-applications/cimd-validation-rules.md#cimd-url-validation-rules) et les [règles de validation JSON CIMD](/docs/fr-ca/get-started/auth0-overview/create-applications/cimd-validation-rules.md#cimd-json-validation-rules), y compris les vérifications SSRF, puis enregistre l’application en tant que client CIMD non validé.
6. **Consentement de l’utilisateur** : Auth0 affiche à l’utilisateur un écran de consentement qui identifie l’application par le `client_name` récupéré dans les métadonnées du CIMD.
7. **Approbation du consentement** : l’utilisateur approuve la demande de consentement.
8. **Redirection** : Auth0 redirige l’utilisateur vers l’application avec un code d’autorisation.
9. **Requête de jeton** : l’application échange le code d’autorisation contre un [jeton d’accès](/docs/fr-ca/secure/tokens/access-tokens.md) auprès du point de terminaison de jetons.
10. **Retour du jeton d’accès** : le serveur d’autorisation Auth0 renvoie un jeton d’accès à l’application. Celle-ci peut désormais accéder à l’API au nom de l’utilisateur.

## Premiers pas