// docs / baas security / auth0 hardening

Liste de contrôle de sécurité Auth0 : 22 éléments

Auth0 est une plateforme identity-as-a-service avec une énorme surface — applications, APIs (serveurs de ressources), tenants, actions, règles (héritées), connexions et grants. Une mauvaise configuration de n'importe lequel est un contournement d'authentification. Cette liste de contrôle est un audit de 22 éléments à travers les applications, listes blanches callback / logout, tokens et rotation de refresh, actions personnalisées, RBAC, détection d'anomalies et surveillance continue. Chaque élément est vérifiable dans le tableau de bord Auth0 en moins de 10 minutes.

Pour la liste de contrôle équivalente sur Clerk, voir Liste de contrôle de sécurité Clerk. Pour le contexte sur pourquoi les mauvaises configurations au niveau de l'identité sont des angles morts des outils IA, voir Pourquoi les outils de codage IA laissent des failles de sécurité.

Type d'application et types de grants

Le type d'application et les types de grants activés sont les paramètres ayant le plus d'impact dans Auth0. Les rater ouvre des classes d'attaques qu'aucun code frontend ne fermera.

Utilisez Application Type = Single Page Application pour les applications navigateur uniquement et Regular Web Application pour les applications rendues côté serveur. Le mauvais type autorise les mauvais grants — p. ex., une Regular Web App avec le grant SPA active le flow Implicit sans PKCE, qui fuit les tokens via des fragments d'URL.
Désactivez le type de grant Implicit sur chaque application. Tableau de bord → Application → Advanced Settings → Grant Types → décochez Implicit. Le flow Implicit retourne les tokens dans des fragments d'URL, où ils sont journalisés dans l'historique du navigateur et les analytics. Utilisez Authorization Code avec PKCE à la place.
Désactivez le grant Password sauf si vous avez un besoin documenté. Le grant Resource Owner Password Credentials (ROPC) requiert que vous gériez les mots de passe utilisateur vous-même — annulant la plupart de ce pourquoi vous avez acheté Auth0. Désactivez-le sauf intégration d'un système hérité.
Activez Authorization Code avec PKCE sur chaque client public. Tableau de bord → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = activé. PKCE est requis pour les applications mobiles et SPAs pour empêcher l'interception de code.

Listes blanches d'URL de callback et logout

Les redirections ouvertes sur le chemin de callback OAuth sont une primitive de vol de token. La liste blanche d'Auth0 est votre seule défense.

Définissez Allowed Callback URLs à votre chemin de callback de production exact — pas de jokers. https://yourapp.com/callback, pas https://yourapp.com/*. Les callbacks à joker permettent aux attaquants de rediriger les tokens vers des sous-chemins arbitraires de votre domaine.
Définissez Allowed Logout URLs à une liste finie. Même règle : URLs explicites uniquement. Une redirection de logout ouverte permet aux attaquants de créer des pages de phishing qui ressemblent à votre état post-logout.
Définissez Allowed Web Origins à votre origine de production uniquement. Utilisé pour l'authentification silencieuse (renouvellement de token via iframe caché). Une origine joker permet aux pages d'attaquants d'effectuer l'auth silencieuse contre votre tenant.
Définissez Allowed CORS origins pour les endpoints API, pas pour l'application. Tenant Settings → Advanced → Allowed CORS origins. Le défaut est vide (restreint) ; n'ajoutez que des origines explicites que vous contrôlez.

Tokens et rotation de refresh

La durée de vie des tokens, la rotation de refresh et l'algorithme de signature décident du rayon d'explosion de toute fuite de token.

Activez la rotation des Refresh Tokens. Application → Refresh Token Settings → Rotation. Chaque rafraîchissement émet un nouveau refresh token et invalide l'ancien. Combiné à l'expiration absolue, cela contient le vol de tokens.
Définissez Refresh Token Reuse Interval à 0 (ou aussi bas que votre tolérance de replay le permet). L'intervalle de réutilisation permet à un token d'être utilisé deux fois dans la même fenêtre — désactivez-le sauf si vous avez une raison spécifique de le garder.
Définissez Absolute Refresh Token Expiry à 14-30 jours, pas à l'infini. Application → Refresh Token Expiration → Absolute Expiration. Auth0 par défaut à Inactivity-seulement, ce qui signifie qu'une session inactive peut persister pendant des années.
Définissez JWT Signature Algorithm à RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 utilise une signature asymétrique, donc le client ne peut pas falsifier les tokens. N'utilisez jamais HS256 pour les applications côté client.
Vérifiez les claims aud et iss sur chaque JWT que votre API reçoit. Utilisez le SDK Auth0 officiel côté serveur — il les vérifie automatiquement. Le parsing JWT fait main saute habituellement la validation d'audience, ce qui est un contournement d'authentification.

Actions et code personnalisé

Les Actions Auth0 (et les Rules héritées) s'exécutent côté serveur lors de la connexion et autres événements de cycle de vie. Elles ont accès à tout le contexte de la requête. Du code non sécurisé ici est une vulnérabilité à l'échelle du tenant.

Ne journalisez jamais event.user ou event.transaction comme objet entier. Ils contiennent des adresses e-mail, des adresses IP et autres PII. Utilisez uniquement la journalisation au niveau du champ, et ne journalisez que ce dont vous avez besoin.
Utilisez le magasin de secrets pour toute clé API ou URL de webhook. Actions → Edit → Secrets. N'inlinez jamais une clé API comme littéral chaîne dans le code d'action — le code est visible à quiconque a un accès éditeur d'Actions sur le tenant.
Validez les entrées avant de les persister comme user_metadata ou app_metadata. Une action en self-service qui écrit event.body.name dans user.user_metadata.display_name est un vecteur de XSS stocké si votre frontend rend ce champ sans échappement.

RBAC et serveurs de ressources

Si vous utilisez Auth0 RBAC, le mapping rôle-à-permission est votre couche d'autorisation. Ratez-le et n'importe quel utilisateur authentifié peut atteindre les endpoints admin.

Définissez les Resource Servers (APIs) explicitement dans le tableau de bord Auth0, pas à la volée. Chaque API a un identifiant (l<code>audience</code>), des scopes et des paramètres de signature. Sans API enregistrée, tous les tokens sont émis pour limplicite « Auth0 Management API » — mauvaise audience.
Configurez les Permissions par API et exigez-les dans votre code avec le claim scope. Ne vérifiez pas l'appartenance au rôle dans votre logique applicative ; vérifiez les scopes dans le token d'accès. Les scopes sont le mécanisme d'autorisation natif OAuth.
Testez qu'un utilisateur authentifié sans le rôle / scope requis ne peut pas atteindre les endpoints privilégiés. Connectez-vous comme utilisateur normal, tentez d'appeler POST /api/admin/users/delete. La réponse doit être 403.

Détection d'anomalies et logs de tenant

Auth0 émet des événements à fort signal. Configurez-les pour alerter votre équipe, pas seulement s'asseoir dans un buffer de logs.

Activez Attack Protection : Bot Detection, Brute Force, Suspicious IP Throttling. Tableau de bord → Security → Attack Protection. Chacun est désactivé par défaut sur les plans gratuits ; activez-les tous pour la production.
Streamez les logs de tenant vers un SIEM ou vos logs applicatifs. Tableau de bord → Monitoring → Streams. Auth0 conserve les logs pendant 30 jours sur la plupart des plans ; la rétention longue durée nécessite un stream vers votre propre système.
Alertez sur les pics de fcoa (auth cross-origin échouée) et fp (connexion échouée). Une rafale de ceux-ci dans une courte fenêtre est du credential stuffing. Routez vers votre canal d'astreinte.

Étapes suivantes

Lancez un scan FixVibe contre votre URL de production — le check baas.clerk-auth0 signale les client secrets Auth0 intégrés dans JavaScript et autres classes d'exposition de fournisseur d'identité. Pour l'équivalent sur Clerk, voir Liste de contrôle de sécurité Clerk. Pour la vue d'ensemble sur les fournisseurs BaaS, lisez Scanner de mauvaises configurations BaaS.