Authentification : connexion, passkeys et sessions

Authentication est une nouveauté. Didit active le produit pour votre application. Tant que ce n’est pas fait, toutes les routes d’exécution de cette application renvoient 404. Les packages du SDK Authentication ne sont pas encore publiés : utilisez donc le flux hébergé et le contrat HTTP décrits dans ces pages.

Authentication permet à vos clients de se connecter à votre application. Ce service est distinct de la connexion à la console Didit ou de la création d’un compte développeur Didit. Il est aussi distinct de la vérification de l’identité d’une personne. Utilisez Authentication seul, ou combinez-le avec la Vérification d’identité et la Surveillance des transactions. La connexion n’approuve pas une vérification et n’autorise pas un paiement. Votre back-end prend ces décisions à partir du résultat propre à chaque produit.

Fonctionnement

Chaque application dispose de sa propre origine de connexion et de son propre émetteur de tokens. Les applications de production et les applications sandbox sont séparées : elles ont des origines, des paramètres et des identités distincts.

Élément	Valeur
Origine par défaut	`https://<slug>.auth.didit.me` pour une application de production, `https://<slug>.sandbox.auth.didit.me` pour une application sandbox. La console affiche la vôtre. Un domaine personnalisé vérifié peut la remplacer.
Pages hébergées	`/sign-in`, `/magic`, `/invite` et `/reset` sur cette origine.
API d’exécution	La même origine, par exemple `POST {origin}/token/` et `GET {origin}/session/`.
Émetteur	L’origine elle-même. La découverte se trouve à `{origin}/.well-known/openid-configuration`.
Clé publiable	`pk_live_...` ou `pk_test_...`. Elle identifie l’application et n’est pas un secret.

Le flux est le code d’autorisation OAuth 2.0 avec PKCE (S256 uniquement) :

Votre application ouvre {origin}/sign-in avec redirect_uri, state, code_challenge et code_challenge_method=S256.
La page hébergée connecte ou inscrit la personne avec les méthodes que vous avez activées, y compris tout second facteur requis.
Le navigateur revient vers votre redirect_uri avec code et state.
Votre application échange le code à POST {origin}/token/ contre un token d’accès, un token ID et un token de rafraîchissement.

Consultez tokens et JWKS pour le contrat des tokens, et méthodes de connexion pour chaque méthode.

Choisissez votre plateforme

JavaScript

Connexion hébergée, rappel, session et déconnexion.

React

État côté client et vues d’application protégées.

Next.js

Sessions côté serveur, routes de rappel et cookies.

iOS

Navigateur système et stockage sécurisé des tokens.

Android

Autorisation par navigateur et rappels de l’application.

React Native

Préparation d’un adaptateur d’authentification natif.

Flutter

Préparation d’un adaptateur d’authentification natif.

Préparez votre application

Demandez à Didit d’activer Authentication pour votre application. Testez d’abord dans une application sandbox.
Enregistrez vos URL de redirection exactes (jusqu’à 50) ainsi que les allowed_origins du navigateur (jusqu’à 50) qui appellent l’API d’exécution.
Activez les méthodes de connexion que vous souhaitez proposer. Didit ID Wallet est toujours activé.
Choisissez vos paramètres de session et de mot de passe (voir ci-dessous).
Testez l’inscription, la connexion, le mot de passe oublié, l’authentification multifacteur, l’expiration de session et la déconnexion avant la mise en production.

Une clé d’accès est liée à son origine. Si vous activez plus tard un domaine personnalisé, les utilisateurs devront enregistrer de nouveau leurs clés d’accès.

URL de redirection

Didit ne renvoie une personne que vers une adresse que vous avez enregistrée. Enregistrez la vôtre dans la console, sous Authentication > Security and sessions > Redirect URLs and allowed origins. Le redirect_uri d’une requête de connexion doit correspondre caractère par caractère à une URL enregistrée : schéma, hôte, port, chemin et requête. Un port différent, une barre oblique finale ou une casse différente désignent une autre adresse.

Application	Ce que vous pouvez enregistrer
Production	Des URL `https://`
Sandbox	Des URL `https://`, et des URL `http://` sur `localhost`, `127.0.0.1` ou `[::1]`

Les caractères génériques, les fragments, les identifiants dans l’URL et les schémas personnalisés sont rejetés. Lorsque l’adresse n’est pas enregistrée, Didit ne redirige jamais vers elle. {origin}/sign-in répond 400 avec une page indiquant quoi enregistrer et où, et POST {origin}/authorize/ répond 400 {"error": "invalid_redirect_uri"}.

Développement local

Testez sur votre propre machine avec votre application sandbox :

Enregistrez votre URL de rappel avec son port, par exemple http://localhost:3000/auth/callback.
Si du code de navigateur appelle l’API d’exécution, par exemple pour échanger le code à POST {origin}/token/, ajoutez aussi l’origine dans Allowed origins : http://localhost:3000, sans chemin ni barre oblique finale.
Lancez la connexion sur l’origine de votre sandbox, https://<slug>.sandbox.auth.didit.me, avec votre clé pk_test_....

localhost, 127.0.0.1 et [::1] sont des adresses distinctes, et chaque port l’est aussi. Enregistrez chacune de celles que vous utilisez. Les applications de production n’acceptent jamais http://. Avant la mise en production, enregistrez votre URL de rappel https:// de production dans votre application de production.

Paramètres de l’application

Vous gérez ces paramètres dans la console, ou avec une session de console autorisée disposant de write:authentication.

Paramètre	Valeurs	Valeur par défaut
`session_lifetime`	`86400`, `604800`, `2592000`, `7776000` secondes	`2592000` (30 jours)
`idle_timeout`	`1800`, `7200`, `86400`, `604800` secondes	`86400` (1 jour)
`multiple_sessions`	`false` déconnecte la personne de ses autres sessions à chaque nouvelle connexion	`true`
`password_min_length`	`8`, `10`, `12`, `14`	`10`
`revoke_on_password_change`	Met fin à toutes les sessions après une réinitialisation du mot de passe	`true`
`signup_policy`	`anyone`, `invited`, `allowed_domains` (avec `allowed_email_domains`, jusqu’à 100)	`anyone`
`allow_subaddresses`	Accepter un `+` dans la partie locale de l’e-mail	`false`
`post_logout_redirect_uri`	Adresse vers laquelle votre application envoie la personne après la déconnexion	Vide
`mfa_policy`	`optional`, `everyone`, `organization_admins`	`organization_admins`
`sign_in_ui`	`hosted` ou `own`	`hosted`

Garder une même personne entre les produits

Chaque identité porte une valeur vendor_data. Il s’agit de l’external_id que vous avez fourni lors de l’importation de la personne, ou de l’identifiant d’identité Didit sinon. Elle apparaît dans le token d’accès, le token d’identité et GET session/. Utilisez la même valeur comme vendor_data lorsque vous créez des sessions de vérification et soumettez des transactions. Les événements d’authentification sont alors rattachés à la même personne dans la console que ses vérifications et transactions. Consultez événements et webhooks. Dérivez vendor_data sur votre backend à partir d’un token vérifié, jamais à partir d’un champ de navigateur non vérifié.

Combinaison de produits	Ce que vous construisez
Authentification	Se connecter, valider les sessions et se déconnecter.
Vérification d’identité + Authentification	Démarrer une vérification après la connexion lorsque votre politique l’exige, avec le `vendor_data` du token.
Surveillance des transactions + Authentification	Soumettre les transactions pour le `vendor_data` de la personne connectée. Les événements de connexion sont associés à la chronologie et aux règles de cette même personne.
Les trois	Un `vendor_data` par personne. Traitez la décision de chaque produit séparément.

Utilisez le prompt d’intégration partagé pour toute combinaison. Consultez protection contre les bots pour les politiques exécutées lors de la connexion.

Guides