Passer au contenu principal
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. Cet exemple utilise les API de cryptographie du navigateur et exige HTTPS, ou localhost en sandbox : consultez le 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.
auth.js
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 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) et lit sa valeur vendor_data. Utilisez cette valeur comme vendor_data lors de la création d’une session de vérification ou de la génération d’un token de transaction. 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.
Dernière modification le 7 novembre 2026