> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Démarrage rapide JavaScript pour l'authentification

> Connectez une application Authentication Didit à la connexion hébergée avec PKCE, validation du callback, contrôle de session et déconnexion.

> [!WARNING]
>
> L'authentification est nouvelle : utilisez cet exemple de flux hébergé avec une application dont l'authentification est activée. Le package `@didit-protocol/auth` n'est pas encore publié : l'API du package ci-dessous est un aperçu, et non un guide de démarrage installable.

## Configurer la connexion hébergée

Enregistrez l'URL de rappel exacte et l'origine de votre site web pour votre application sandbox. Copiez son origine de connexion (`https://<slug>.sandbox.auth.didit.me`) depuis la console, comme décrit dans la [vue d'ensemble](https://docs.didit.me/fr/authentication/overview.md). Cet exemple utilise les API de cryptographie du navigateur et exige HTTPS, ou localhost en sandbox : consultez [le développement local](https://docs.didit.me/fr/authentication/overview.md#développement-local) pour savoir quoi enregistrer.

L'application gère le `state` et le vérificateur PKCE. La connexion hébergée gère les écrans de mot de passe, d'e-mail, de passkey, de téléphone, de SSO et de MFA obligatoire. Aucune clé API ne doit figurer dans ce code.

```javascript auth.js theme={null}
// Replace both values with your registered application configuration.
const AUTH_BASE = "https://YOUR_SLUG.sandbox.auth.didit.me/";
const REDIRECT_URI = "https://YOUR_APP_ORIGIN/auth/callback";
const PENDING = "didit.auth.pending";
let tokens = null;

function base64url(bytes) {
  return btoa(String.fromCharCode(...bytes))
    .replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "");
}

export async function signIn() {
  const verifier = base64url(crypto.getRandomValues(new Uint8Array(32)));
  const state = base64url(crypto.getRandomValues(new Uint8Array(32)));
  const digest = await crypto.subtle.digest("SHA-256", new TextEncoder().encode(verifier));
  sessionStorage.setItem(PENDING, JSON.stringify({ verifier, state, startedAt: Date.now() }));
  const url = new URL("sign-in", AUTH_BASE);
  url.search = new URLSearchParams({
    redirect_uri: REDIRECT_URI,
    state,
    code_challenge: base64url(new Uint8Array(digest)),
    code_challenge_method: "S256",
  }).toString();
  window.location.assign(url.href);
}

export async function handleCallback() {
  const query = new URLSearchParams(window.location.search);
  const saved = sessionStorage.getItem(PENDING);
  sessionStorage.removeItem(PENDING);
  history.replaceState(null, "", window.location.pathname);
  if (!saved) throw new Error("Start sign-in again.");
  const pending = JSON.parse(saved);
  if (query.get("state") !== pending.state || Date.now() - pending.startedAt > 600000) {
    throw new Error("Invalid or expired sign-in. Start again.");
  }
  if (query.has("error") || !query.get("code")) throw new Error("Sign-in was not completed.");
  const response = await fetch(new URL("token/", AUTH_BASE), {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      grant_type: "authorization_code",
      code: query.get("code"),
      code_verifier: pending.verifier,
      redirect_uri: REDIRECT_URI,
    }),
  });
  if (!response.ok) throw new Error("Code exchange failed. Start sign-in again.");
  tokens = await response.json();
  return getSession();
}

export async function getSession() {
  if (!tokens) return null;
  const response = await fetch(new URL("session/", AUTH_BASE), {
    headers: { Authorization: `Bearer ${tokens.access_token}` },
    cache: "no-store",
  });
  if (!response.ok) {
    tokens = null;
    throw new Error("Session check failed. Sign in again.");
  }
  return response.json();
}

export async function signOut() {
  const current = tokens;
  tokens = null;
  if (!current) return;
  const response = await fetch(new URL("session/", AUTH_BASE), {
    method: "DELETE",
    headers: { Authorization: `Bearer ${current.access_token}` },
  });
  if (response.status !== 204) throw new Error("Local state cleared; server logout failed.");
}
```

Appelez `signIn()` depuis votre bouton de connexion. Sur la page de rappel enregistrée, appelez `handleCallback()` une seule fois, affichez un état de chargement et montrez son erreur en cas d'échec. Utilisez `getSession()` pour l'utilisateur courant et `signOut()` pour la déconnexion. Le rappel retire son code de la barre d'adresse avant d'envoyer une requête.

Cet exemple minimal conserve les tokens en mémoire et relance une connexion après un rechargement de la page ou l'expiration du token d'accès. Pour des sessions persistantes, utilisez votre backend et des cookies sécurisés, ou implémentez une [rotation des tokens d'actualisation](https://docs.didit.me/fr/authentication/tokens-and-jwks.md) sérialisée. Ne placez jamais de tokens d'actualisation dans des URL ni dans des journaux. Une vérification de session côté client ne contrôle que l'affichage : votre backend doit valider l'appelant à chaque requête protégée.

## Aperçu de la version du SDK d'authentification

Le cœur prévu de `@didit-protocol/auth` expose `createDiditAuth({publishableKey})`, `signIn()`, `handleRedirectCallback()`, `getSession()`, `getToken()`, `onAuthStateChange` et `signOut()`, avec `vendorData` sur l'identité. Il est destiné à ajouter la collecte automatique des signaux d'appareil et un point d'entrée serveur avec `verifyToken()`.

La clé publiable est `pk_live_` (application en production) ou `pk_test_` (application sandbox), suivie de l'encodage base64url, sans padding, de l'origine de votre application.
Le SDK envoie ses appels d'API à cette origine.
La clé est publique : elle identifie l'application et n'est pas un secret.

### Step-up et réauthentification dans l'aperçu

* `stepUp({ action, amount?, currency?, redirectUri? })` appelle le `POST step-up/` de votre application pour vérifier si `action` nécessite une vérification d'identité.
  `action` vaut `payout`, `bank` ou `contact`, et un versement exige `amount`.
  Lorsqu'une de vos règles de step-up s'applique, la méthode redirige vers la page de vérification renvoyée par Didit.
* `handleStepUpCallback(url?)` s'exécute sur la page vers laquelle la personne revient.
  Elle lit `?step_up=<id>`, la retire de la barre d'adresse et récupère le résultat avec `GET step-up/{id}/`.
* `reauthenticate({ method? })` reconnecte la même personne, sur la page hébergée (`method: "redirect"`, valeur par défaut) ou avec une passkey (`method: "passkey"`, uniquement sur le domaine de connexion Didit de votre application).
  Après la page hébergée, terminez-la avec `handleRedirectCallback()`.
  Si quelqu'un d'autre la termine, elle est rejetée avec `step_up_user_mismatch` et la session d'origine est conservée.

Les deux méthodes de step-up renvoient `{ id, status, approved, rule, method }`, où `status` vaut `not_required`, `pending`, `approved`, `review`, `declined` ou `expired`.
`redirectUri` prend par défaut l'adresse de redirection du client et doit correspondre exactement à l'une des adresses de redirection enregistrées de votre application : lorsqu'une vérification est requise, Didit refuse toute autre adresse.
Avant que votre backend n'agisse sur un step-up, récupérez à nouveau celui-ci avec `GET step-up/{id}/` et le token d'accès de la personne, car un résultat transmis par le navigateur peut être modifié.

Une connexion headless peut aussi renvoyer `protection_required` lorsque les règles de protection de votre application la signalent.
La personne la termine alors avec le code que Didit lui a envoyé par e-mail (`protection.verify({ code })`) ou avec une passkey (`protection.passkey()`). `methods` indique lesquels de ces deux moyens elle peut utiliser.

N'installez pas une version devinée et n'écrivez pas de code reposant sur des options de rappel supposées. Confirmez les exports du package publié, l'émetteur et la configuration des clés avant de remplacer l'exemple hébergé. Les méthodes par mot de passe, code e-mail, lien magique, passkey, téléphone, MFA, connexion sociale, step-up et agent dépendront de l'API prise en charge par cette version.

## Ajouter d'autres produits

Votre backend vérifie le token d'accès (voir [tokens et JWKS](https://docs.didit.me/fr/authentication/tokens-and-jwks.md)) et lit sa valeur `vendor_data`. Utilisez cette valeur comme `vendor_data` lors de la [création d'une session de vérification](https://docs.didit.me/fr/sessions-api/create-session.md) ou de la [génération d'un token de transaction](https://docs.didit.me/fr/transaction-monitoring/sdk-transaction-submission.md). Une connexion réussie n'implique pas qu'un de ces deux produits ait approuvé l'utilisateur.

Avant la mise en production, testez l'inscription, la reconnexion, l'annulation, un state incohérent, un code réutilisé, le mot de passe oublié, la MFA, l'expiration et la déconnexion sur votre application sandbox activée.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.