> ## 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. # Méthodes de connexion Didit : passkeys, codes, SSO > Avec Didit, configurez mot de passe, code e-mail, lien magique, code SMS, passkey, réseaux sociaux, SSO, Didit ID Wallet, MFA et réinitialisation. > [!WARNING] > > L'authentification est une nouveauté. La page de connexion hébergée propose toutes les méthodes présentées sur cette page. Les endpoints JSON listés ici sont destinés aux équipes qui créent leurs propres écrans de connexion (`sign_in_ui: "own"`). 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. | Méthode | Nom | Configuration | | - | - | - | | Mot de passe | `password` | Également nécessaire pour l'inscription par e-mail avec un mot de passe. | | Code par e-mail | `code` | Aucune. | | Lien magique | `magic` | Aucune. Pages hébergées uniquement. | | Code par téléphone | `phone` | Envoyez le `workflow_id` d'un workflow de Vérification du téléphone. | | Clé d'accès | `passkey` | Aucune. | | Connexion sociale | `google`, `microsoft`, `apple`, `github` | Votre propre `client_id` et `client_secret`. Les applications sandbox peuvent utiliser les applications de test de Didit à la place (`credential_source: "didit_test"`). | | SSO d'organisation | `sso` | Une connexion SAML ou OIDC par organisation cliente. | | Didit ID Wallet | `wallet` | Toujours activé. Il ne peut pas être désactivé. | 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](https://docs.didit.me/fr/authentication/tokens-and-jwks.md)). Au lieu d'un code, un appel de connexion peut renvoyer l'une de ces étapes. Terminez l'étape, puis vous recevrez le code. | Réponse | Étape suivante | | - | - | | `mfa_required` avec `challenge` et `factors` | Envoyez un code TOTP ou un code de récupération, ou utilisez une clé d'accès (voir [MFA](#mfa)). | | `mfa_enrollment_required` avec `challenge` et `uri` | La politique MFA exige un authentificateur. Enregistrez-le avec `POST mfa/setup/`. | | `protection_required` avec `challenge` et `methods` | Une politique de [protection contre les bots](https://docs.didit.me/fr/authentication/bot-protection.md) demande une preuve supplémentaire. | | `verification_required` avec `verification_url` | Vos paramètres de vérification exigent une détection du vivant ou une vérification d'identité à l'inscription ou à la connexion. Dirigez la personne vers `verification_url` (valable 30 minutes) ; le code est fourni après une vérification approuvée. | ## 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](https://docs.didit.me/fr/authentication/bot-protection.md#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. | Appel | Corps | Résultat | | - | - | - | | `POST passkeys/begin/` | `{transaction}` | `{challenge, options}` pour `navigator.credentials.get()`. Aucune liste d'identifiants n'est envoyée : le navigateur propose donc toutes les clés d'accès de votre origine. | | `POST passkeys/complete/` | `{challenge, credential}` | Un code de connexion, ou une étape suivante. | | `POST passkeys/register/` | Vide, avec `Authorization: Bearer ` | Options pour `navigator.credentials.create()`. | | `POST passkeys/confirm/` | `{challenge, credential}`, avec le même token | `{id}` de la nouvelle clé d'accès. | * 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=` 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](https://docs.didit.me/fr/authentication/tokens-and-jwks.md), ou consultez [protection contre les bots](https://docs.didit.me/fr/authentication/bot-protection.md) pour les verrouillages et les défis. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.