Skip to main content
Dynamic Client Registration (DCR) permet aux applications clientes de s’enregistrer automatiquement en envoyant une requête API à un terminal d’enregistrement. Bien que cette approche offre une certaine souplesse pour des architectures très dynamiques, elle comporte des risques de sécurité importants si elle n’est pas protégée adéquatement. Pour les déploiements MCP en production, nous recommandons d’utiliser l’enregistrement CIMD plutôt que DCR. CIMD offre une sécurité accrue grâce à des identités vérifiées par domaine et simplifie la gestion des informations d’identification (enregistrez une fois, déployez partout). Il élimine aussi les risques liés aux terminaux d’enregistrement ouverts.

​
Informations requises

Toutes les applications créées par DCR dans Auth0 sont des applications tierces dotées de mesures de sécurité renforcées. Vous devez définir des autorisations par défaut, c’est-à-dire un ensemble de base d’API et de permissions accessibles à toutes les applications tierces. Cette étape est obligatoire pour DCR, puisqu’il est impossible d’y configurer l’accès aux API application par application. Dans Auth0 Dashboard :
  1. Naviguez vers Applications > APIs et sélectionnez l’API.
  2. Accédez à l’onglet Settings (Paramètres).
  3. Faites défiler jusqu’à Default Permissions for Third-Party Applications (Autorisations par défaut pour les applications tierces).
  4. Sélectionnez Authorized (Autorisé) pour User-Delegated Access (Accès délégué par l’utilisateur) ou Client Access (Accès client).
  5. Sélectionnez les permissions à accorder, puis sélectionnez Sauvegarder.

​
Activer DCR

Par défaut, DCR est désactivé pour tous les locataires. Vous pouvez activer DCR dans les paramètres du locataire de l’Auth0 Dashboard :
  1. Accédez à Dashboard > Paramètres > Avancé.
  2. Activez l’option Dynamic Client Registration (DCR).
  3. Sélectionnez Sauvegarder.

​
Les dangers d’un terminal DCR ouvert

Auth0 prend en charge un terminal DCR ouvert : si vous activez cette fonctionnalité sans protections supplémentaires, n’importe qui sur Internet peut créer des applications dans votre locataire. Vous vous exposez ainsi à plusieurs menaces :
  • Épuisement des ressources : un acteur malveillant pourrait exécuter un script pour enregistrer des millions d’applications et ainsi provoquer un déni de service en atteignant la limite d’applications de votre locataire.
  • Tentatives d’accès non autorisé : des attaquants peuvent enregistrer leurs propres clients pour sonder votre système à la recherche de vulnérabilités ou tenter d’obtenir un accès non autorisé.
  • Mauvaise configuration du locataire : des enregistrements automatisés et non vérifiés peuvent mener à la création de clients aux paramètres non sécurisés, ce qui introduit des points faibles dans votre posture de sécurité.
  • Manque de supervision : sans une surveillance rigoureuse, il devient difficile de savoir qui enregistre des clients et dans quel but.

​
Sécuriser un terminal DCR ouvert

L’Open Dynamic Client Registration (Open DCR) permet des intégrations MCP flexibles, mais si elle n’est pas authentifiée, elle expose votre locataire à des abus. Sans mesures de sécurité, n’importe qui peut créer des applications dans votre locataire, ce qui risque d’entraîner l’épuisement des ressources, des tentatives d’accès non autorisées ou une mauvaise configuration du locataire.
Ces options de sécurité sont offertes uniquement aux clients Entreprise. Pour mettre à niveau votre plan, communiquez avec l’équipe des ventes d’Auth0.
Pour atténuer ces risques, vous pouvez adopter l’une ou l’autre des deux approches suivantes : Limitez les plages d’adresses IP ou les domaines autorisés à accéder aux terminaux DCR de votre locataire grâce à la fonctionnalité intégrée Liste de contrôle d’accès de locataire (ACL) d’Auth0. Cette approche protège à la fois votre domaine personnalisé et le nom d’hôte canonique d’Auth0 (p. ex., tenant.auth0.com), ce qui assure une protection complète. Elle est idéale lorsque vous connaissez les plages d’adresses IP des clients légitimes (comme celles de votre réseau interne ou de certains fournisseurs infonuagiques) et que vous souhaitez appliquer un contrôle d’accès fondé sur le réseau sans avoir à gérer d’infrastructure supplémentaire.

​
Mandataire inverse

Placez un mandataire inverse (comme Cloudflare) devant votre domaine personnalisé afin de limiter le débit des requêtes, de les filtrer et de les authentifier avant qu’elles n’atteignent le terminal DCR. Cette approche vous permet de contrôler le volume de requêtes, de mettre en œuvre une logique d’authentification personnalisée et de surveiller les tendances du trafic. Notez toutefois que, même avec un mandataire inverse sur votre domaine personnalisé, le terminal DCR demeure accessible par votre nom d’hôte Auth0 canonique (p. ex., tenant.auth0.com), ce qui permet de contourner le mandataire. Pour une protection complète, combinez cette approche avec l’ACL du locataire.

​
Défense en profondeur

Les deux approches peuvent être combinées pour une sécurité en profondeur. Quelle que soit l’approche choisie, surveillez régulièrement le journal de votre locataire afin de repérer tout schéma d’enregistrement suspect.
Les deux approches peuvent être combinées pour une sécurité en profondeur. Surveillez régulièrement le journal de votre locataire afin de repérer tout schéma d’enregistrement suspect.

​
Surveillance de l’activité DCR

Consultez régulièrement le journal de votre locataire afin de repérer des comportements suspects, comme la création rapide d’applications ou des enregistrements provenant de sources inattendues. Pour surveiller les enregistrements de clients :
  1. Accédez à Monitoring > Logs dans votre Auth0 Dashboard
  2. Utilisez la requête de recherche : type:sapi AND description:"Dynamic client registration" Cette requête filtre les opérations réussies de la Management API (sapi) liées précisément aux événements de Dynamic Client Registration.
  3. Examinez les entrées du journal afin de repérer :
    • Un volume inhabituel : plusieurs clients créés en peu de temps
    • Des sources inattendues : des enregistrements provenant d’adresses IP ou d’emplacements inconnus
    • Des comportements suspects : des noms de clients similaires, des URL de rappel pointant vers des domaines inattendus ou des clients créés en dehors des heures ouvrables

​
Récupérer les journaux à l’aide de l’Auth0 CLI

Vous pouvez également récupérer les journaux DCR par programmation à l’aide de l’Auth0 CLI :
Envisagez de configurer des flux de journaux pour acheminer les événements DCR vers votre SIEM ou votre plateforme de surveillance et ainsi recevoir des alertes automatisées en cas d’activité d’enregistrement suspecte.

​
Authentification et autorisation pour les serveurs MCP

Lorsqu’un serveur MCP est exposé à Internet, il doit être sécurisé. La spécification MCP recommande d’utiliser OAuth 2.1 pour sécuriser ces interactions. Le serveur MCP peut ainsi déléguer l’authentification à un serveur d’autorisation dédié et gérer, au moyen de permissions, le contrôle d’accès pour différents clients, utilisateurs et actions.

​
Configuration obligatoire du serveur

Pour qu’un client puisse interagir avec votre serveur, la spécification MCP exige que vous annonciez votre configuration d’autorisation et que vous utilisiez des réponses HTTP standards.
  1. Utilisez l’en-tête WWW-Authenticate pour les erreurs 401 Lorsqu’un client effectue une requête sans jeton valide, votre serveur doit renvoyer un statut 401 Unauthorized. Point essentiel : cette réponse doit inclure l’en-tête WWW-Authenticate, qui pointe vers l’URL des métadonnées que vous avez configurée précédemment. Le client sait ainsi qu’une authentification est requise et où obtenir exactement les métadonnées d’autorisation.
  2. Annoncez votre serveur d’autorisation au moyen des métadonnées de ressource protégée (RFC 9728) Votre serveur MCP doit indiquer aux clients où obtenir une autorisation. Pour ce faire, vous devez exposer un terminal de métadonnées. Créez sur votre serveur un terminal .well-known/oauth-protected-resource qui renvoie un objet JSON pointant vers votre locataire Auth0. Les clients MCP peuvent ainsi découvrir automatiquement vos terminaux d’autorisation, sans configuration manuelle.