Méthodes de connexion Didit : passkeys, codes, SSO

Activez une méthode avec PUT methods/{name}/ et {"enabled": true} sur l’API de gestion de l’authentification de votre application, ou depuis la console. La connexion hébergée n’affiche que les méthodes que vous avez activées. Chaque appel JSON ci-dessous commence par une transaction issue de POST authorize/. Cette transaction est valable 10 minutes. Une connexion réussie renvoie {code, redirect_uri, state}. Échangez le code sur POST token/ dans les 60 secondes (voir tokens et JWKS). Au lieu d’un code, un appel de connexion peut renvoyer l’une de ces étapes. Terminez l’étape, puis vous recevrez le code.

​

Mot de passe

POST password/ accepte transaction, email et password.

• Un mot de passe doit respecter votre password_min_length (8, 10, 12 ou 14 caractères ; 10 par défaut). Les mots de passe courants et entièrement numériques sont rejetés avec password_policy. Lorsque le contrôle des mots de passe compromis est activé, un mot de passe connu comme compromis est rejeté avec password_breached.
• Seules les personnes disposant d’un e-mail vérifié peuvent se connecter avec un mot de passe.
• Un mauvais mot de passe, une adresse e-mail inconnue, un e-mail non vérifié, un compte verrouillé et un compte bloqué reçoivent tous la même réponse : 400 {"error": "invalid_credentials"}. Votre interface ne peut pas déterminer laquelle de ces situations s’est produite, et un attaquant non plus.

​

Inscription

L’inscription vérifie d’abord l’e-mail. Appelez POST email/start/ avec purpose: "signup", email et password, puis POST email/complete/ avec le code. Le compte est créé avec un e-mail vérifié.

• signup_policy détermine qui peut s’inscrire : anyone, invited (uniquement avec un lien d’invitation) ou allowed_domains.
• Avec allow_subaddresses: false (par défaut), une adresse contenant un + dans la partie locale est rejetée.
• Lorsque votre image de marque définit des liens vers les conditions générales ou la politique de confidentialité, le formulaire d’inscription hébergé demande à la personne de les accepter.

​

Code par e-mail

POST email/start/ accepte transaction, purpose (login ou signup) et email, et renvoie 202 {challenge, expires_in: 600}. La personne reçoit un code à 6 chiffres valable 10 minutes. POST email/complete/ accepte transaction, purpose, challenge et code. Vous disposez de 5 tentatives, après quoi la personne doit demander un nouveau code. La page hébergée propose un nouveau code après 30 secondes. Un code de connexion envoyé à une adresse sans compte en crée un si votre signup_policy le permet. C’est l’inscription sans mot de passe.

​

Lien magique

La page hébergée envoie un lien de connexion valable 15 minutes. Il reste lié à la transaction PKCE d’origine, de sorte que le lien ne fonctionne que dans le flux qui l’a initié. La personne confirme la connexion sur la page que le lien ouvre. Il n’existe pas d’endpoint JSON pour les liens magiques.

​

Code par téléphone

POST phone/start/ accepte transaction, phone et un channel facultatif (sms, valeur par défaut, ou whatsapp). Le numéro est normalisé au format E.164. L’appel renvoie 202 {challenge, expires_in: 600}. POST phone/complete/ accepte transaction, challenge et le code à 6 chiffres. Vous disposez de 5 tentatives.

• Les codes par téléphone sont envoyés via la Vérification du téléphone de Didit. Activez la méthode avec le workflow_id d’un workflow qui contient une Vérification du téléphone.
• La première connexion par téléphone ne crée un compte que si signup_policy vaut anyone.
• Si l’envoi échoue, l’appel renvoie 503 {"error": "delivery_unavailable"}.

​

Clés d’accès

Les clés d’accès utilisent WebAuthn. La partie de confiance est l’origine de connexion de votre application. Didit demande un identifiant détectable (clé résidente) et exige toujours une vérification de l’utilisateur, par exemple une empreinte digitale, un visage ou le code PIN de l’appareil. Didit ne demande pas d’attestation.

• Un challenge de clé d’accès est valable 5 minutes.
• L’ajout d’une clé d’accès nécessite une session créée dans les 5 dernières minutes. Sinon, l’appel renvoie 403 {"error": "reauthentication_required"}. Reconnectez d’abord la personne.
• Une connexion par clé d’accès compte comme authentification multifacteur.
• Après l’inscription, la page hébergée propose d’ajouter une clé d’accès (passkeys/setup/begin/ et passkeys/setup/complete/).
• Les applications Android enregistrées sur l’application peuvent utiliser les mêmes clés d’accès.

​

Connexion sociale

La connexion avec Google, Microsoft, Apple et GitHub utilise vos propres identifiants d’application OAuth, définis avec PUT methods/{provider}/ et credentials: {client_id, client_secret}. Le rappel du fournisseur se trouve sur votre origine de connexion. La première fois qu’une personne se connecte avec un fournisseur, elle doit aussi prouver qu’elle possède l’adresse e-mail, au moyen d’un code (POST social/email/start/ et POST social/email/verify/). Les connexions ultérieures avec ce fournisseur ignorent cette étape. GitHub ne peut pas prouver une connexion récente ; il n’est donc pas proposé lorsque vous envoyez prompt=login ou max_age.

​

SSO d’organisation

Le SSO d’organisation permet à l’entreprise d’un client de se connecter via son propre fournisseur d’identité SAML ou OIDC. Configurez-le pour chaque organisation cliente à organizations/{id}/sso/ avec protocol (saml ou oidc), enabled et config.

• Vous pouvez envoyer à l’équipe informatique du client un lien de configuration valable 7 jours.
• Les métadonnées de votre fournisseur de service SAML sont publiées à l’adresse {origin}/sso/saml/metadata/.
• La connexion hébergée retrouve la connexion à partir du domaine e-mail vérifié de la personne, ou à partir de organization=<slug> dans l’URL de connexion.

​

Didit ID Wallet

Les personnes déjà vérifiées avec Didit peuvent se connecter avec leur Didit ID Wallet. Cette méthode est toujours activée. Le verified_identity de la session contient alors ce que la personne a choisi de partager.

​

MFA

Le second facteur est une application d’authentification (TOTP) avec des codes de récupération, ou une clé d’accès.

• mfa_policy détermine qui doit utiliser le MFA : optional, everyone ou organization_admins (valeur par défaut). Toute personne ayant enregistré une application d’authentification doit toujours l’utiliser.
• Pour enregistrer une application d’authentification, appelez POST mfa/enroll/ avec une session récente (créée dans les 5 minutes précédentes). La réponse renvoie {challenge, uri} ; affichez uri sous forme de QR code. Envoyez ensuite le premier code à POST mfa/confirm/. La réponse contient 10 codes de récupération à usage unique. Affichez-les une seule fois.
• À la connexion, envoyez un code TOTP ou un code de récupération à POST mfa/complete/ avec le challenge. Vous disposez de 5 tentatives. Pour utiliser une clé d’accès à la place, appelez POST mfa/passkey/begin/ puis POST mfa/passkey/complete/.
• Les codes utilisent des intervalles de 30 secondes. Un code déjà accepté ne peut pas être réutilisé.
• Les codes SMS et e-mail ne sont pas disponibles comme second facteur.

​

Mot de passe oublié et réinitialisation

POST password-reset/start/ prend email et renvoie 202 {"status": "sent", "expires_in": 1800}. La réponse est la même, que l’adresse ait un compte ou non. Le lien de réinitialisation est valable 30 minutes. POST password-reset/complete/ prend token et password et renvoie {"status": "password_changed"}. Il effectue également les actions suivantes :

• il lève un verrouillage,
• il met fin à toutes les sessions lorsque revoke_on_password_change est activé (valeur par défaut),
• il invalide les autres codes et liens en attente pour cette personne.

​

Invitations

Avec signup_policy: "invited", seules les personnes invitées peuvent s’inscrire. Un lien d’invitation est valable 7 jours et ouvre la page hébergée /invite. Continuez avec tokens et JWKS, ou consultez protection contre les bots pour les verrouillages et les défis.