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.

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 peuvent être enregistrées avec CIMD; elles sont assujetties à des mesures de sécurité renforcées. Pour en savoir plus, consultez Enregistrer des applications avec CIMD.

Pour les clients CIMD enregistrés dynamiquement, les administrateurs de locataire peuvent utiliser les profils d’application 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, 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 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.
• 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" :

https://example-client.com/mcp-metadata.json

{
  "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. Pour en apprendre davantage sur les types de clients pris en charge, consultez la section Informations requises.

​

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

​

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 2 : Autorisation

​

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, et le CIMD selon les règles de validation CIMD; 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 :

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 et les règles de validation JSON CIMD, 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 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