Domaines Personnalisés Auth0

Piloter les domaines personnalisés Auth0 de bout en bout : API Management Auth0, fournisseur DNS, polling de vérification, et la configuration qui assemble tout. Détecte le fournisseur DNS de l'utilisateur (Cloudflare, Route 53, Azure DNS, ou autre) et automatise la création d'enregistrements lorsque le fournisseur le supporte.

Vue d'ensemble

Cette skill est basée sur les capacités, non sur les étapes. Elle groupe le travail qu'un utilisateur pourrait vouloir faire en cinq capacités distinctes (setup, troubleshoot, manage, remove, health check), chacune avec son propre flux dans un fichier de référence dédié. Le SKILL.md principal agit comme un hall d'accueil : il contient le tableau des capacités, les concepts clés, les prérequis et les erreurs courantes qui s'appliquent à tous les flux. Quand un utilisateur invoque la skill, choisissez la capacité correspondante dans le tableau, chargez son fichier de référence, et suivez ce flux.

La conception basée sur les capacités correspond à la façon dont les utilisateurs viennent vraiment au travail des domaines personnalisés Auth0 : « en configurer un », « le mien est cassé », « changer quelque chose », « en supprimer un », ou « ma configuration fonctionne-t-elle toujours ? ». Chaque intention correspond à un flux distinct avec ses propres vérifications de sécurité et points de passage.

Style d'interaction

Posez les questions sous forme de texte conversationnel simple. N'utilisez jamais d'éléments d'interface structurés (par exemple, AskUserQuestion) sauf pour une seule confirmation oui/non immédiatement avant une action destructrice ou irréversible (create, PATCH, delete). Pour tout le reste :

• Routage des capacités : présenter une liste numérotée et attendre la réponse de l'utilisateur
• Collecte d'entrées : poser une question ciblée à la fois ; attendre une réponse avant la suivante
• Valeurs libres (noms d'hôte, noms de domaine, etc.) : demander directement — ne pas les envelopper dans un widget qui force un clic avant la saisie

Exemple du bon modèle pour le routage des capacités :

Que voulez-vous faire ?

1. Configurer un domaine personnalisé
2. Dépanner la vérification
3. Gérer un domaine existant
4. Supprimer un domaine
5. Vérifier la santé du domaine (lecture seule, point de départ sûr)

Exemple du bon modèle pour une entrée unique :

Quel est le nom d'hôte que vous voulez configurer ? (par exemple, login.example.com)

Triage des codes d'erreur — VÉRIFIEZ D'ABORD

Si le message de l'utilisateur porte principalement sur un code d'erreur HTTP de l'API Management (par exemple, « j'ai reçu un 403 », « pourquoi cela retourne un 409 ? », un corps d'erreur collé, une entrée de journal avec un code de statut), répondez d'abord à partir de ce tableau. Ne passez pas à des connaissances générales Auth0 — cela conduit à de mauvais conseils en particulier dans le cas 403 du tier Free. Ce n'est qu'après la réponse du code d'erreur que vous pouvez proposer de router vers la capacité correspondante si l'utilisateur veut continuer (par exemple, « voulez-vous que je vous guide dans Setup avec ce correctif en place ? »).

Référence complète des codes d'erreur avec tous les cas et résolutions : references/api.md#error-codes.

Capacités

Quand cette skill est invoquée et que l'utilisateur ne pose PAS de question sur un code d'erreur, demandez-lui quelle capacité il veut en utilisant une simple liste numérotée (voir Style d'interaction ci-dessus). Router vers Check domain health en premier quand l'utilisateur signale un problème sans cause connue spécifique, ou quand il ne sait pas quelle capacité il lui faut ; c'est le démarreur sûr en lecture seule qui les pointera vers le bon suivi.

Choisissez une capacité, puis suivez le flux dans son fichier de référence. Les sections Prérequis et Concepts Clés ci-dessous s'appliquent à toutes les capacités.

Concepts Clés

Le schéma complet et le comportement du token / iss vivent dans references/advanced.md.

Prérequis

Ceux-ci s'appliquent à toute capacité qui écrit sur le tenant. Check domain health est en lecture seule et peut être exécutée en premier pour vérifier ceux-ci.

Accès à l'API Management Auth0

Toutes les capacités utilisent l'API Management. Soit :

• La CLI Auth0 (auth0 ...) authentifiée au tenant cible (auth0 tenants use <name>), ou
• Une application Machine-to-Machine avec les scopes dans references/api.md.

Vérifiez le tenant actif immédiatement avant la première commande CLI Auth0 dans une capacité, pas à l'invocation de la skill. Ne pas vérifier le tenant avant que l'utilisateur ait choisi une capacité. Si une capacité n'utilise que des outils non-CLI (par exemple, recherches DNS, Cloudflare MCP, appels directs d'API Management via curl), ignorer entièrement la vérification du tenant.

Quand la capacité choisie utilise la CLI Auth0, exécutez ceci avant la première commande CLI :

auth0 tenants list

Cherchez la ligne marquée comme active (ou vérifiez le champ active dans la sortie JSON). Affichsignez le tenant actif à l'utilisateur et demandez-lui de confirmer que c'est la cible prévue. S'il est incorrect, arrêtez et faites exécuter à l'utilisateur :

auth0 tenants use <tenant-name>

Puis re-confirmez avant de continuer. Pour les appels mutants (create, PATCH, delete), exigez une confirmation explicite. Pour les flux CLI en lecture seule, afficher le nom du tenant (et le nommer dans le rapport de sortie) suffit — ne jamais supposer que le tenant actif est correct basé sur le seul contexte conversationnel.

Accès au fournisseur DNS (pour Set up, Troubleshoot, et Remove)

Configurer un domaine personnalisé écrit un CNAME. Supprimer un domaine personnalisé en supprime un. Dépanner la vérification peut suggérer un correctif qui nécessite une édition DNS. Ce dont la skill a besoin dépend du tier du fournisseur :

• Tier 1 Cloudflare : Cloudflare MCP connecté. Sinon, la skill demande à l'utilisateur d'exécuter claude mcp add --transport http cloudflare https://mcp.cloudflare.com/mcp et d'autoriser dans le navigateur.
• Tier 2 AWS Route 53 : Credentials AWS configurées (variables env, config partagée, ou session SSO). Vérifiées avec aws sts get-caller-identity.
• Tier 3 Azure DNS : Azure CLI connecté. Vérifié avec az account show.
• Tier 4 autre : pas d'accès programmatique ; l'utilisateur ajoute manuellement l'enregistrement dans le tableau de bord de son fournisseur.

Exigences de plan pour l'automatisation : Aucun des trois tiers automatisés ne nécessite un plan payant du côté du fournisseur DNS. Les opérations CRUD d'enregistrement DNS Cloudflare via le MCP fonctionnent sur le plan Free (les zones Free créées après septembre 2024 sont plafonnées à 200 enregistrements DNS par zone ; le CNAME d'Auth0 en compte un). Route 53 est au paiement à l'utilisation (~0,50 $/zone hébergée/mois + coûts de requête, non dans le tier gratuit AWS). Azure DNS est basé sur un abonnement sans gating de tier ; l'identité connectée a besoin du rôle DNS Zone Contributor. Détails complets par tier dans les sous-fichiers par fournisseur sous references/providers/ (routeur : references/providers.md).

Carte de crédit en dossier (tenants tier Free)

Les domaines personnalisés sont disponibles sur tous les tiers de plan, y compris Free. Les tenants Free ont besoin d'une carte de crédit en dossier pour la vérification d'identité (la carte ne sera pas facturée). Sans elle, POST /custom-domains retourne 403. Correctif au Dashboard → Tenant Settings → Billing (ou la section Teams pour les tenants gérés par Teams).

Surfacer cela comme la cause probable sur tout 403 plutôt que de suggérer une mise à niveau de plan.

Erreurs Courantes

Index rapide ; chaque entrée renvoie au traitement canonique dans le fichier de capacité pertinent.

Skills Associées

• auth0-branding : Personnaliser l'apparence de Universal Login (les modèles de page nécessitent un domaine personnalisé vérifié)
• auth0-organizations : Branding spécifique à l'organisation pour la multi-location B2B

Références

• references/capability-setup.md : Configurer un domaine personnalisé
• references/capability-troubleshoot.md : Dépanner la vérification
• references/capability-manage.md : Gérer les domaines existants
• references/capability-remove.md : Supprimer un domaine personnalisé
• references/capability-health.md : Vérifier la santé du domaine
• references/providers.md : Routeur de fournisseur DNS — NS → carte des fournisseurs ; liens dans les sous-fichiers par fournisseur sous references/providers/ (cloudflare.md, route53.md, azure-dns.md, manual.md). Ouvrir uniquement le sous-fichier correspondant au fournisseur détecté.
• references/examples.md : Exemples cURL plus automatisation CI/CD de bout en bout et modèles multi-environnement
• references/api.md : Référence d'endpoint, commandes CLI, codes d'erreur, scopes
• references/advanced.md : MCD, domaine par défaut, en-tête auth0-custom-domain, certificats auto-gérés, comportement du token iss, approfondissement du dépannage de vérification

Docs Externes

• Custom Domains Overview
• Auth0-Managed Certificates
• Self-Managed Certificates
• Multiple Custom Domains
• Default Custom Domain
• Configure Features to Use Custom Domains
• Troubleshoot Custom Domains
• Cloudflare MCP Server