Auth0 via Stripe Projects (Mode Strict)

Vous êtes responsable de l'approvisionnement correct, de la configuration et de la validation des ressources Auth0 avec Stripe Projects. Votre objectif n'est pas seulement de créer des ressources, mais de s'assurer qu'elles sont entièrement fonctionnelles, correctement configurées et vérifiablement opérationnelles pour l'application cible.

Prérequis

Cette compétence requiert un espace de travail Stripe Projects actif. Avant de continuer, confirmez que la CLI est disponible :

stripe projects status

Si stripe projects n'est pas reconnu (command not found) ou que le projet n'a pas été initialisé, arrêtez-vous ici — cette compétence ne peut pas être utilisée en dehors d'un contexte Stripe Projects.

Fallback : Utilisez la compétence auth0-quickstart à la place. Elle fournit la configuration Auth0 via la CLI Auth0 (auth0 login, auth0 apps create) et ne dépend pas de Stripe Projects.

Règles Fondamentales

Utilisez stripe projects CLI comme plan de contrôle principal
Consultez la spécification OpenAPI Auth0 Management API pour informer les propriétés valides de vos payloads de configuration.
Ne devinez jamais les clés de config ou les capacités ; utilisez le schéma OpenAPI spec.
Inspectez toujours le catalogue avant d'agir pour vous assurer que le type de ressource est supporté.
Vérifiez toujours après les modifications
Préférez la configuration complète à la configuration minimale
Ne déclarez pas le succès sans validation
Si Stripe Projects ne peut pas effectuer une action requise, basculez vers : stripe projects open auth0 et décrivez explicitement les étapes manuelles restantes. Cependant, vous devez d'abord épuiser toutes les options de config CLI.

Workflow Obligatoire (Ne Pas Sauter les Étapes)

1) Découvrir l'État Actuel

Exécutez :

stripe projects status
stripe projects services list
stripe projects catalog auth0 --json

Utilisez ces données aux côtés de la spécification OpenAPI Auth0 pour déterminer :

les types de ressources Auth0 disponibles dans Stripe Projects
les champs de config supportés (mappés au schéma Auth0 API)
les paramètres obligatoires/optionnels
les limitations de Stripe Projects

Si client n'est pas dans le catalogue, arrêtez-vous et utilisez uniquement les types de ressources déployables disponibles.

2) Classifier le Type d'Application

Déterminez le type d'application Auth0 correct avant de rien créer :

Regular Web App → applications rendues côté serveur (par ex. Next.js avec backend/session)
SPA → applications uniquement navigateur utilisant les tokens directement
Native → applications mobiles/bureau
M2M → authentification service-à-service

Si c'est flou :

inspectez la structure du dépôt
vérifiez les dépendances installées pour les SDKs Auth0 et déduisez le type d'application de l'objectif du SDK
vérifiez les patterns de routage/authentification

Par défaut, adoptez Regular Web App pour les frameworks rendus côté serveur sauf si clairement SPA ou M2M.

Ne procédez jamais sans choisir explicitement un type d'application.

3) Aligner l'Intégration du Code

Utilisez le SDK Auth0 officiel pour le langage et le framework du projet. Réutilisez un SDK Auth0 existant s'il en est déjà installé. Ne mélangez pas les patterns d'authentification.

4) Lire Avant d'Écrire (Étape Obligatoire Post-Installation)

Après avoir installé tout SDK Auth0 (ou en découvrir un déjà installé), vous DEVEZ compléter ces étapes avant d'écrire tout code d'intégration :

Vérifiez la version installée en utilisant le gestionnaire de paquets du projet.
Lisez le README ou la documentation locale du SDK pour la version installée. Le répertoire du paquet installé est la source de vérité — pas la documentation web, pas les données d'entraînement. Si le README référence un guide de migration ou une documentation des changements de rupture, lisez aussi cela.
Identifiez le pattern d'initialisation du SDK depuis la documentation locale — pas de la mémoire ou des données d'entraînement. Les SDKs Auth0 ont eu des changements de rupture à travers les versions majeures (par ex., v4 de @auth0/nextjs-auth0 a changé de initAuth0() à new Auth0Client()). Vos données d'entraînement peuvent refléter une version obsolète.

Ce n'est qu'après avoir complété les trois étapes que vous pouvez écrire le code d'intégration.

Si la version majeure installée diffère de celle attendue, signalez-le à l'utilisateur avant de procéder (par ex., « Le SDK installé est v4, qui utilise un pattern d'initialisation différent de v3 »).

Cette étape existe parce que les APIs des SDKs changent à travers les versions majeures, et les erreurs de build dues à des patterns obsolètes sont coûteuses à déboguer. La documentation du paquet installé localement est l'unique source de vérité pour l'API de la version installée.

5) Dériver les URLs Requises (Ne Pas Deviner)

Déterminez :

Base URL (par ex. http://localhost:3000)
Callback URL (par ex. /auth/callback)
Logout URL
Web origins

Déduisez à partir de :

conventions de framework
routes existantes
fichiers env
README/config
config du serveur de développement

Règles :

N'inventez PAS de domaines de production
Incluez toujours localhost pour le développement
N'omettez PAS les URLs requises
N'utilisez PAS de wildcards sauf si explicitement justifiés

6) Créer ou Mettre à Jour le Client Auth0 (Configuration Complète Uniquement)

Formulez le payload JSON --config en utilisant la spécification OpenAPI Auth0 Management API.

Les payloads de création mappent directement vers l'endpoint POST /v2/clients.
Les payloads de mise à jour mappent directement vers l'endpoint PATCH /v2/clients/{id}.

Créer :

stripe projects add auth0/client --name "<name>" --config '<json>' -y

Mettre à jour :

stripe projects update <name> auth0/client --config '<json>' -y

Exigences :

CRITIQUE : Vous DEVEZ configurer les URIs directement via la CLI. N'instruisez PAS l'utilisateur de configurer callbacks, allowed_logout_urls, ou web_origins dans le dashboard. Ce sont des champs API supportés et ils doivent être inclus dans votre payload --config.
Vous pouvez et devriez utiliser la CLI pour définir des configurations complètes, incluant callbacks, name, description, app_type, allowed_logout_urls, web_origins, et tout le reste supporté par la spec.
Si --name est utilisé, incluez "name" dans la config
Incluez toujours la configuration complète des URIs quand supportée.
Ne soumettez pas de configs partielles pour des demandes de configuration complète.

7) Synchroniser + Vérifier (Obligatoire)

Exécutez :

stripe projects status
stripe projects env
stripe projects env --pull

Confirmez :

la ressource existe
la config est appliquée
les variables env sont disponibles localement
l'état du projet est cohérent

Si la vérification est incomplète, déclarez explicitement ce qui ne peut pas être confirmé.

8) Fallback Dashboard (Quand Nécessaire)

Si Stripe Projects ne peut pas configurer quelque chose :

stripe projects open auth0

Ensuite, spécifiez clairement :

les noms de champs exacts
les valeurs exactes à saisir
où dans le dashboard les définir

Exigences de Configuration Auth0

Pour toute application web, assurez-vous que TOUT est défini via le flag --config :

Allowed Callback URLs (callbacks)
Allowed Logout URLs (allowed_logout_urls)
Allowed Web Origins (web_origins, si applicable)

Configuration locale type (ajustez si nécessaire) :

http://localhost:3000
http://localhost:3000/auth/callback

Ne prétendez pas que la configuration est complète si celles-ci manquent de votre exécution CLI.

Exigences de Sortie

Incluez toujours :

Ce qui a été découvert à partir du catalogue/statut
Type d'application choisi + justification
Commandes CLI exactes utilisées ou recommandées (incluant les payloads JSON complets)
Valeurs finales de configuration (notamment URLs, validées contre la spec OpenAPI)
Résultats de vérification
Toutes les étapes manuelles requises (si applicable, mais limitées aux champs API non supportés)

Gestion des Défaillances

Si quelque chose échoue :

Vérifiez à nouveau la sortie du catalogue et le schéma de la spec OpenAPI Auth0
Supprimez uniquement les champs non supportés ou mal formatés
Ne devinez PAS les remplaçants
Validez la disponibilité du service (services list)
Utilisez le fallback dashboard si nécessaire (uniquement comme dernier recours pour les champs non supportés)

Contraintes Strictes

N'instruisez jamais l'utilisateur de configurer callbacks ou allowed_logout_urls dans le dashboard. Vous devez exécuter cela via la CLI.
Ne fabriquez jamais de clés de config (référencez toujours la spec OpenAPI Auth0)
N'assumez jamais les URLs de production
Ne sautez jamais la vérification
Ne laissez jamais la config des URIs incomplète
Ne contournez jamais Stripe Projects quand il supporte l'opération
N'écrivez jamais le code d'intégration avant de vérifier la version du SDK installée et de lire son README local
N'assumez jamais les patterns d'initialisation du SDK à partir des données d'entraînement — vérifiez toujours contre le README/docs du SDK installé localement

Référence des Commandes

stripe projects status
stripe projects services list
stripe projects catalog auth0 --json
stripe projects add auth0/client --name "<name>" --config '{"callbacks": ["http://localhost:3000/api/auth/callback"], "allowed_logout_urls": ["http://localhost:3000"]}' -y
stripe projects update <name> auth0/client --config '<json>' -y
stripe projects env
stripe projects env --pull
stripe projects open auth0

stripe-projects-auth0