--- term: 'Authentification Sans Mot de Passe (Passwordless)' seoTitle: 'Authentification sans mot de passe : passkeys, magic links, WebAuthn' headline: "Qu'est-ce que l'authentification sans mot de passe (passwordless) ?" slug: authentification-sans-mot-de-passe category: auth-security shortDefinition: "L'authentification sans mot de passe est un modèle de connexion qui vérifie l'identité par une clé de l'appareil ou la biométrie, et non un secret mémorisé." relatedTerms: - multi-factor-authentication-mfa - oauth-2-social-login - json-web-token-jwt - identity-access-management-iam contrastsWith: - multi-factor-authentication-mfa aboutTerms: - 'Passkeys' - 'WebAuthn' - 'Magic Links' faq: - question: "Qu'est-ce que l'authentification sans mot de passe en termes simples ?" answer: "Se connecter sans taper de mot de passe : vous prouvez votre identité avec ce que vous avez — un appareil qui détient une clé cryptographique, une boîte de réception, une clé de sécurité — ou avec ce que vous êtes, via la biométrie qui la déverrouille. La propriété déterminante : il n'existe aucun secret partagé que quiconque pourrait voler, réutiliser ou hameçonner." - question: "L'authentification sans mot de passe est-elle plus sûre que les mots de passe ?" answer: "Face aux attaques qui causent réellement les brèches — hameçonnage, credential stuffing, réutilisation, force brute — nettement, car il n'y a aucun secret à voler côté serveur ni à soutirer à l'utilisateur. Elle n'est pas inviolable pour autant : les codes peuvent être interceptés, les appareils volés, et des parcours de récupération faibles sapent des portes d'entrée solides." - question: "Que sont les passkeys et comment fonctionnent-elles ?" answer: "Des identifiants FIDO bâtis sur WebAuthn. À l'enregistrement, votre appareil crée une paire de clés et n'envoie au site que la clé publique ; à la connexion, l'appareil signe le défi du site après un déverrouillage local par biométrie ou code PIN. L'identifiant est lié au vrai domaine, si bien qu'un site sosie obtient une signature sans valeur — d'où la résistance à l'hameçonnage." - question: "Quelle est la différence entre passkeys synchronisées et liées à l'appareil ?" answer: "Les passkeys synchronisées sont des copies chiffrées de bout en bout, distribuées par un gestionnaire d'identifiants — elles survivent à la perte d'un appareil et facilitent la récupération, au prix d'une confiance accordée au compte de synchronisation. Les clés liées à l'appareil ne quittent jamais le matériel — assurance maximale, aucune copie de secours. Les recommandations fédérales américaines actuelles acceptent les passkeys synchronisées aux niveaux d'assurance courants." - question: "Les magic links sont-ils sûrs ?" answer: "Plus sûrs que les mots de passe pour la plupart des utilisateurs, et exactement aussi sûrs que la boîte de réception où ils arrivent — l'e-mail est le véritable authentificateur, c'est pourquoi les lignes directrices du NIST n'acceptent pas l'e-mail comme authentificateur hors bande. L'hygiène : tokens à usage unique, expiration courte, génération aléatoire, liens en HTTPS uniquement." - question: "Le sans mot de passe, est-ce la même chose que la MFA ?" answer: "Non, et l'opposition populaire entre les deux est fausse : la MFA ajoute des facteurs, le sans mot de passe retire celui qu'on mémorise — et une passkey déverrouillée par biométrie est les deux à la fois : la possession de l'appareil plus l'inhérence qui le déverrouille, du multifacteur en un seul geste, sans mot de passe nulle part." - question: "Que se passe-t-il si je perds mon appareil ?" answer: "Les passkeys synchronisées se restaurent via le gestionnaire d'identifiants ; les clés liées à l'appareil, non, par conception. La discipline : enrôler au moins deux authentificateurs sur des appareils distincts, conserver des codes de récupération hors ligne, et garder à l'esprit qu'un repli faible — un OTP par e-mail derrière une passkey — plafonne silencieusement tout le compte à la solidité de ce repli." - question: "Comment ajouter la connexion sans mot de passe à une app ?" answer: "Par ajout, pas par rupture : conservez la connexion existante, proposez passkeys ou magic links comme chemin privilégié, enrôlez une méthode de repli dès la configuration, puis reléguez le mot de passe plus tard. Pour WebAuthn, utilisez une bibliothèque serveur open-source maintenue pour vérifier la cérémonie plutôt que de coder à la main les contrôles de défi et d'origine." codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'W3C Web Authentication (WebAuthn) Level 3' url: 'https://www.w3.org/TR/webauthn-3/' - name: 'FIDO Alliance — Passkeys' url: 'https://fidoalliance.org/passkeys/' - name: 'NIST SP 800-63B — Digital Identity Guidelines: Authentication' url: 'https://pages.nist.gov/800-63-4/sp800-63b.html' - name: 'CISA — Implementing Phishing-Resistant MFA' url: 'https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf' - name: 'Passwordless authentication — Wikipedia' url: 'https://en.wikipedia.org/wiki/Passwordless_authentication' cta: title: 'Le sans mot de passe, en une seule Cloud Function' text: "Construisez une connexion par magic link sur Back4app avec Cloud Code — génération du token, e-mail et émission de la session côté serveur — ou branchez n'importe quel fournisseur d'OTP ou de passkeys via les adaptateurs d'authentification personnalisés de Back4app." linkText: 'Commencez gratuitement' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-15' translationKey: passwordless-authentication --- **L'authentification sans mot de passe est un modèle de connexion qui vérifie l'identité par une clé de l'appareil ou la biométrie, et non un secret mémorisé.** Dans le langage des facteurs : elle retire "ce que vous savez" et authentifie par "ce que vous avez" et "ce que vous êtes" — et dans ses variantes les plus fortes, aucun secret partagé n'existe : le serveur stocke une clé publique, la clé privée ne quitte jamais votre appareil, et il n'y a rien à hameçonner, à rejouer en credential stuffing ni à dérober en masse. Les mots de passe perdurent non parce qu'ils sont bons, mais parce qu'ils sont installés ; le sans mot de passe est la migration enfin engagée à grande échelle. ## Points clés | Question | Réponse | | --- | --- | | L'échange | Le facteur connaissance sort ; possession + inhérence entrent | | La référence | Passkeys (FIDO2/WebAuthn) — clés liées à l'origine, résistantes à l'hameçonnage | | Le gradient honnête | Passkeys > push/TOTP > magic link (lien magique) > SMS — chacun hérite de quelque chose | | vs. MFA | Une fausse rivalité — une passkey déverrouillée par biométrie *est* de la MFA, le mot de passe en moins | | Le maillon faible | La récupération — un repli plus faible que la porte d'entrée devient la porte | ## La cérémonie WebAuthn, démystifiée La machinerie derrière chaque invite de passkey — deux cérémonies, aucun secret en transit : ```text ENREGISTREMENT CONNEXION 1 le serveur envoie un défi aléatoire 1 le serveur envoie un nouveau défi 2 navigator.credentials.create() 2 navigator.credentials.get() 3 l'appareil crée une paire de clés ; 3 déverrouillage local biométrie/PIN, la biométrie ou le PIN la protège l'appareil SIGNE le défi 4 clé publique → serveur ; la clé 4 le serveur vérifie avec la clé privée ne quitte jamais l'appareil publique stockée → session émise L'identifiant est lié à l'ORIGINE : un domaine sosie obtient une signature qui ne se vérifie nulle part. C'est cette propriété — et non la biométrie — que désigne "résistant à l'hameçonnage". ``` La rampe d'accès plus douce que la plupart des apps livrent en premier — les magic links, où la boîte de réception fait office de facteur : **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Magic link via Cloud Code: possession of the inbox is the factor // 1 · Request: generates a single-use token, emails the link await Parse.Cloud.run('requestMagicLink', { email: 'ada@example.com' }); // 2 · The link opens the app with the token; exchange it for a session const { sessionToken } = await Parse.Cloud.run('redeemMagicLink', { token: tokenFromLink, // single-use, expires in 15 minutes }); await Parse.User.become(sessionToken); // logged in — no password exists ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Magic link via Cloud Code: possession of the inbox is the factor // 1 · Request: generates a single-use token, emails the link await ParseCloudFunction('requestMagicLink') .execute(parameters: {'email': 'ada@example.com'}); // 2 · The deep link opens the app with the token; exchange for a session final result = await ParseCloudFunction('redeemMagicLink') .execute(parameters: {'token': tokenFromLink}); // single-use, 15 min // Adopt the returned session token — logged in, no password exists ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Magic link via Cloud Code: possession of the inbox is the factor // 1 · Request: generates a single-use token, emails the link _ = try await Cloud.run(name: "requestMagicLink", parameters: ["email": "ada@example.com"]) // 2 · The universal link opens the app with the token; exchange for a session let result = try await Cloud.run(name: "redeemMagicLink", parameters: ["token": tokenFromLink]) try await User.become(sessionToken: result["sessionToken"] ?? "") // logged in — no password exists ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Magic link via Cloud Code: possession of the inbox is the factor // 1 · Request: generates a single-use token, emails the link ParseCloud.callFunction>( "requestMagicLink", mapOf("email" to "ada@example.com")) // 2 · The deep link opens the app with the token; exchange for a session val result = ParseCloud.callFunction>( "redeemMagicLink", mapOf("token" to tokenFromLink)) // single-use, 15 min ParseUser.becomeInBackground(result["sessionToken"] as String) // logged in — no password exists ``` ## Passkeys vs. magic links vs. OTP : les méthodes, classées Toute méthode sans mot de passe hérite de la sécurité de quelque chose — le tableau dit de quoi : | Méthode | Facteur | Résistante à l'hameçonnage ? | Hérite du risque de | Récupération | | --- | --- | --- | --- | --- | | **Passkey (synchronisée)** | Avoir + être | **Oui** — liée à l'origine | Le compte du gestionnaire d'identifiants | Restaurée sur tous les appareils | | **Clé de sécurité (liée à l'appareil)** | Avoir (+ être) | **Oui** | La garde physique | Aucune — enrôlez une clé de secours | | Code TOTP / app d'authentification | Avoir | Non — les codes peuvent être relayés | Le secret d'enrôlement | Nouvel enrôlement | | Approbation push | Avoir | Non — et bombardable | L'attention de l'utilisateur | Nouvel enrôlement | | Magic link | Avoir (boîte de réception) | Non | **Votre compte e-mail** | Il *est* le chemin de récupération | | Code SMS à usage unique | Avoir (numéro) | Non | L'opérateur — SIM swap | Le plus faible de la liste | La ligne qui compte passe entre les deux premières lignes et le reste : codes, liens et approbations peuvent tous être relayés par un proxy d'hameçonnage en temps réel ; [les signatures liées à l'origine, non](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) — la même ligne de partage que dans le [classement des méthodes de l'article sur la MFA](/glossary/fr/authentification-multifacteur-mfa/), parce que c'est la même ligne. ```mermaid flowchart LR accTitle: Pourquoi une passkey met en échec un proxy d'hameçonnage accDescr: Avec une passkey, l'appareil signe un défi lié à l'origine authentique, si bien qu'un faux site qui relaie la connexion reçoit une signature dont la vérification échoue. Avec un code à usage unique, la victime peut être amenée à le saisir sur le faux site, qui le relaie avec succès vers le vrai. V["Victime"] -->|"saisit le code OTP"| F["Faux site
(proxy)"] -->|"relaie — ça marche"| R["Vrai site"] V2["Victime avec passkey"] -->|"l'appareil signe pour
l'origine FACTICE"| F2["Faux site"] -.->|"signature invalide
sur la vraie origine"| X["Échec"] ``` ## Synchronisée ou liée à l'appareil : le vrai trade-off Les passkeys se répartissent en deux modèles de garde, et la différence relève de la politique, pas du pinaillage. Les **passkeys synchronisées** vivent dans un gestionnaire d'identifiants et se répliquent, chiffrées de bout en bout, sur les appareils d'un utilisateur — perdre son téléphone devient un non-événement, ce qui explique que l'adoption grand public ait enfin décollé ; la contrepartie en confiance, c'est que le compte de synchronisation devient le joyau de la couronne, gardé par ses propres parcours de récupération. Les **clés liées à l'appareil** (clés de sécurité matérielles, authentificateurs attestés en entreprise) ne quittent jamais le matériel — le choix à forte assurance pour les administrateurs et les accès réglementés, avec "enrôlez une clé de secours" pour tout plan de récupération. Les [recommandations actuelles du NIST](https://pages.nist.gov/800-63-4/sp800-63b.html) ont tranché le débat pour le cas général : les authentificateurs synchronisés sont acceptables aux niveaux d'assurance standard, les authentificateurs liés à l'appareil étant réservés au niveau le plus élevé. ## Le problème de la récupération, encore Le sans mot de passe aiguise la plus vieille règle de l'authentification : **un compte ne vaut que son parcours de récupération le plus faible.** Une connexion par passkey avec un repli OTP par e-mail est, pour un attaquant, une connexion OTP par e-mail avec quelques étapes de plus. Il n'existe pas de "réinitialisation" pour une clé liée à l'appareil — par conception — donc la discipline se joue en amont : enrôler deux authentificateurs ou plus sur des appareils distincts dès la configuration, émettre des codes de récupération hors ligne, traiter les méthodes de repli comme des décisions de sécurité et non comme des facilités de support, et faire du retrait d'un authentificateur un événement soumis à authentification renforcée, journalisé et générateur d'alerte. Les déploiements qui font l'impasse le réapprennent par leur support. ## Pas contre la MFA — une fusion L'opposition "sans mot de passe vs. MFA" des pages comparatives d'éditeurs est une fausse alternative. La [MFA](/glossary/fr/authentification-multifacteur-mfa/) signifie plusieurs *catégories* de facteurs ; le sans mot de passe signifie aucun secret mémorisé. Une passkey déverrouillée par une empreinte digitale est **les deux** : la possession de l'appareil plus l'inhérence au déverrouillage — du multifacteur en un seul geste, où l'élément hameçonnable est supprimé plutôt que complété. La conséquence pratique : les organisations ne choisissent pas entre les deux ; elles passent de "mot de passe + second facteur" à "passkey", un point strictement plus solide sur la même courbe. ## Cas d'usage courants - **Connexion aux apps grand public** — les passkeys comme chemin mis en avant ; les magic links comme repli à faible friction. - **Commerce à visites répétées** — là où la friction de connexion se mesure en chiffre d'affaires, la connexion en un geste se rentabilise d'elle-même. - **Accès des collaborateurs** — des authentificateurs résistants à l'hameçonnage imposés aux administrateurs et aux rôles à hauts privilèges. - **Produits nativement sans mot de passe** — un onboarding par lien e-mail ou OTP, sans jamais livrer de champ mot de passe. - **Moments d'authentification renforcée** — une cérémonie passkey comme réauthentification avant un paiement, une suppression ou un export de clés. ## Devriez-vous passer au sans mot de passe ? Matrice de décision | Situation | Penchez pour | | --- | --- | | Nouvelle app grand public | Passkeys + repli par magic link ; pas de champ mot de passe | | App existante, large base d'utilisateurs | Coexistence : ajoutez les passkeys comme option privilégiée, reléguez les mots de passe plus tard | | Comptes admin / à hauts privilèges | Résistant à l'hameçonnage uniquement — passkeys ou clés matérielles | | Public sur appareils partagés ou anciens | Magic links / OTP, avec des attentes réalistes | | Accès réglementé, à forte assurance | Authentificateurs liés à l'appareil, attestation, clés de secours enrôlées | | "Juste ajouter de la sécurité ce sprint" | [La MFA sur la connexion existante](/glossary/fr/authentification-multifacteur-mfa/) maintenant ; le sans mot de passe ensuite | ## Limites et trade-offs - **La couverture n'est pas universelle.** Tous les sites, navigateurs et stacks d'entreprise ne prennent pas encore en charge les passkeys ; les mots de passe subsistent comme échafaudage de compatibilité, d'où l'intérêt de la coexistence plutôt que d'une migration en rupture. - **L'écosystème détient les clés.** Les passkeys synchronisées délèguent la garde aux gestionnaires d'identifiants des plateformes — une dépendance de disponibilité et de confiance dont vous héritez au lieu de l'opérer. - **La récupération est le vrai chantier.** La cérémonie la plus solide assortie d'un parcours de réinitialisation faible relève du théâtre ; budgétez l'UX d'enrôlement et la politique de repli, pas seulement l'intégration WebAuthn. - **Un sans mot de passe plus faible reste plus faible.** Les magic links et le SMS retirent le mot de passe sans ajouter de résistance à l'hameçonnage — un progrès, pas la destination. - **Les modèles de support changent.** Les tickets "mot de passe oublié" deviennent des tickets "appareil perdu" ; le support a besoin de procédures de vérification qui ne deviennent pas la nouvelle faille d'ingénierie sociale. ## Le sans mot de passe sur Back4app Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Le sans mot de passe y est un pattern que vous composez à partir des briques de la plateforme, et les onglets de code montrent le cas canonique : un flux de magic link construit avec deux fonctions Cloud Code — `requestMagicLink` génère un token à usage unique et à expiration courte, le stocke sur l'utilisateur et envoie le lien par e-mail ; `redeemMagicLink` le valide côté serveur et renvoie un [token de session](/glossary/fr/gestion-des-sessions/) que le SDK adopte, si bien que le client ne manipule jamais d'identifiants. Au-delà des liens, les adaptateurs d'authentification personnalisés de Back4app branchent des fournisseurs d'OTP et de passkeys sur le même mécanisme `authData` qui fait fonctionner la [connexion sociale](/glossary/fr/oauth-2-connexion-sociale/) — un seul objet utilisateur, plusieurs méthodes de connexion, associables et dissociables par utilisateur, soit la discipline de récupération (plusieurs méthodes enrôlées) exprimée en modélisation de données. Les sessions restent révocables de bout en bout : quelle que soit la cérémonie, l'identifiant qu'elle émet peut être invalidé dès que quelque chose paraît anormal.