Auth0

Auth0 exécute une Action avant de créer un utilisateur qui s'inscrit avec un mot de passe ou un code sans mot de passe (une connexion Database ou Passwordless), et cette Action peut appeler Bot Protection et refuser l'inscription. La page d'inscription est celle d'Auth0, sur le domaine d'Auth0, donc l'Action n'a pas de cookie _kz : la décision repose sur l'IP et le User-Agent.

Le tag

Placez le tag sur vos propres pages, là où les gens arrivent avant de s'inscrire et là où ils se connectent et paient, pour que ces décisions aient le token :

<script src="https://korzen.dev/v1/tag.js" data-site-key="YOUR_SITE_KEY" async></script>

L'appel

L'Action. Auth0 lui donne 20 secondes en tout ; l'appel respecte votre timeout, et tout autre cas laisse passer l'inscription :

// Auth0 Dashboard: Actions, Triggers, pre-user-registration; a new Action.
// Add the secret KORZEN_API_KEY to the Action.
exports.onExecutePreUserRegistration = async (event, api) => {
  let d = null;
  try {
    const res = await fetch("https://korzen.dev/v1/decide", {
      method: "POST",
      headers: { Authorization: `Bearer ${event.secrets.KORZEN_API_KEY}`, "Content-Type": "application/json" },
      body: JSON.stringify({
        ip: event.request.ip,
        user_agent: event.request.user_agent,
        ja4: event.security_context?.ja4 || undefined, // behind Cloudflare only: left out without it
        headers: { "accept-language": event.request.language },
        path: "/signup",
        method: "POST",
      }),
      signal: AbortSignal.timeout(200),
    });
    if (res.ok) d = await res.json();
  } catch {} // fail open
  if (d?.action === "block") {
    api.access.deny("korzen_block", "We could not create your account.");
    return;
  }
  // "challenge": Auth0's own CAPTCHA or MFA, if your plan has them
  if (d?.request_id) api.user.setAppMetadata("korzen_request_id", d.request_id);
};

Auth0 donne à l'Action la langue et le User-Agent du navigateur, mais aucun des autres en-têtes de la requête : l'appel ne transmet donc que accept-language. Les en-têtes qu'un même build de navigateur envoie à l'identique, que Bot Protection lit dans les appels de votre propre serveur, manquent ici.

Sur un tenant dont le trafic passe par Cloudflare (les offres Enterprise d'Auth0), l'événement a aussi security_context.ja4 : le JA4 du handshake TLS du visiteur avec la périphérie d'Auth0, sous la forme que Bot Protection lit de Cloudflare devant votre propre serveur. L'appel l'envoie comme ja4 quand il est là ; sans lui, le champ est omis.

L'IP du visiteur

event.request.ip est l'adresse qui a atteint Auth0, déjà celle du visiteur : rien à configurer. Sur un domaine personnalisé derrière votre propre proxy, voyez les réglages de domaine personnalisé d'Auth0 pour l'IP du visiteur.

Les décisions d'Auth0 arrivent sans le token du tag. Une fois que Bot Protection a vu votre tag sur d'autres pages, un token absent ajoute un peu au score (no_token), jamais assez pour bot à lui seul.

Appliquer l'action

Ne lisez que action. Avec block, répondez avec la même erreur que l'action affiche quand elle échoue pour toute autre raison, pour qu'un bot n'apprenne rien. Avec challenge, utilisez la vérification que vous avez déjà (un CAPTCHA, un code par e-mail ou téléphone) ; sans aucune, continuez. Le compte commence en mode monitor, où action est toujours allow : rien ne change pour les visiteurs tant que vous n'activez pas le mode block.

Garder le request_id

Chaque réponse a un request_id. Gardez-le avec ce que l'action a créé, dans une colonne du compte ou de la commande, ou dans une ligne de log avec leur identifiant. Il désigne cette décision quand vous nous interrogez à son sujet, et vous permet de retrouver plus tard quelle réponse a laissé entrer un faux compte.

Tester sur votre machine

Utilisez votre tenant de développement. Dans l'éditeur d'Action, Test l'exécute avec un événement d'exemple ; inscrivez-vous ensuite sur votre page de login, et la décision apparaît sur la page Décisions du tableau de bord sous /signup. Vérifiez le fail-open avec un secret KORZEN_API_KEY erroné : l'inscription passe.

Erreurs fréquentes

• Les inscriptions sociales. Google, GitHub et autres ne déclenchent pas le trigger pre-user-registration ; une Action post-login peut interroger Bot Protection à leur sujet lors de leur première connexion.
• Appeler /v1/decide depuis le navigateur. L'API key atteindrait chaque visiteur ; l'appel a sa place sur votre serveur.
• Pas de timeout, ou une erreur qui bloque l'inscription. Toute réponse autre que 200, ou l'absence de réponse à temps, signifie : laissez passer le visiteur.