Le magic link authentifie un utilisateur en lui envoyant par courriel un lien à usage unique : un clic, et la session s'ouvre. Il supprime le mot de passe, ce qui est un progrès réel sur l'expérience et sur la réutilisation de secrets. Mais il ne supprime pas le problème : il le déplace vers la boîte mail, qui devient le facteur d'authentification de fait — avec toutes ses faiblesses.
La mécanique, étape par étape
- L'utilisateur saisit son adresse électronique sur la page de connexion.
- Le service génère un jeton aléatoire, l'associe à une demande de connexion, lui donne une durée de validité et un usage unique.
- Le jeton est intégré à une URL et envoyé par courriel.
- L'utilisateur clique. Le service vérifie le jeton, l'invalide, puis ouvre la session.
Techniquement, le jeton joue le rôle d'un mot de passe à usage unique — à ceci près qu'il n'est pas mémorisé mais transporté. Trois paramètres déterminent le niveau réel : la durée de validité, l'unicité d'usage, et le fait que la session s'ouvre ou non dans le navigateur d'origine.
Ce qui pose problème
Le courriel devient la clé maîtresse. Quiconque accède à la boîte mail peut demander un lien pour chaque service qui utilise ce mécanisme. Le compte de messagerie ne protège plus seulement les messages : il commande l'ensemble des accès. Or c'est aussi la cible privilégiée du phishing et du credential stuffing.
Le canal n'est pas maîtrisé. Un courriel traverse des relais, des passerelles de filtrage, des sauvegardes, parfois des archives à long terme. Il peut être transféré, restauré, consulté depuis un poste partagé. Certaines passerelles de sécurité pré-cliquent les liens pour les analyser, ce qui consomme un jeton à usage unique et provoque des échecs de connexion — ou, selon l'implémentation, ouvre une session imprévue.
Aucune liaison à l'origine. Contrairement à FIDO2/WebAuthn, rien ne rattache la preuve au domaine légitime. Un attaquant en relais fait saisir l'adresse à la victime sur une page de façade, le vrai service envoie le lien, la victime le reçoit et clique — la session est ouverte, et le relais capte le cookie.
Le lien est un secret dans une URL. Une URL se copie, se colle dans une conversation, apparaît dans un historique de navigation, parfois dans des journaux de serveurs intermédiaires. Un secret qui voyage dans une adresse web est un secret difficile à cloisonner.
Le délai crée de la friction. Basculer vers la messagerie, attendre l'acheminement, revenir : c'est une rupture de parcours, et une dépendance opérationnelle à la disponibilité du service d'envoi.
Comparaison avec les autres méthodes sans mot de passe
| Méthode | Secret transporté | Lié à l'origine | Dépendance externe | Résiste au relais temps réel |
|---|---|---|---|---|
| Magic link | oui (jeton dans l'URL) | non | fournisseur de messagerie | non |
| OTP par e-mail | oui (code) | non | fournisseur de messagerie | non |
| SMS-OTP | oui (code) | non | opérateur télécom | non |
| Passkey / FIDO2 | non | oui | aucune au moment de l'usage | oui, sur la connexion |
| Facteur cognitif | non | canal éphémère à usage unique | aucune | oui, y compris au niveau de l'action |
Le tableau met en évidence l'écart : le magic link appartient à la famille des méthodes qui transmettent quelque chose de rejouable. Il est plus confortable qu'un mot de passe, il n'est pas plus résistant face à un attaquant actif.
Où le magic link reste défendable
Il ne s'agit pas de le proscrire, mais de le cantonner à ce qu'il fait bien.
- Applications grand public à faible enjeu : lecture de contenus, préférences, suivi de commande. Le rapport confort/risque y est favorable.
- Premier accès ou invitation, avec une durée de validité courte et une continuation obligatoire vers une méthode plus robuste.
- Parcours secondaires où le compte ne donne accès à aucune donnée sensible ni à aucune opération financière.
À l'inverse, il est inadapté aux accès administrateurs, aux applications métiers sensibles, aux parcours financiers et à tout contexte soumis à une exigence d'authentification forte au sens de DSP2 — un lien cliqué n'établit ni deux catégories de facteurs ni de lien dynamique avec le montant et le bénéficiaire.
Si le magic link est déjà en place, quatre réglages améliorent la situation à faible coût : réduire fortement la durée de validité, imposer l'ouverture de session dans le navigateur ayant initié la demande, neutraliser l'effet des pré-clics de passerelles par une confirmation explicite, et journaliser chaque émission avec son contexte.
Le fond du problème
Le magic link illustre une tendance générale du sans-mot-de-passe : supprimer le secret mémorisé sans supprimer le secret transmissible. Tant qu'une valeur circule — code, lien, approbation — elle peut être captée, relayée ou provoquée.
C'est la différence de nature qu'introduit le facteur cognitif : le canal ouvert par un QR code dynamique est éphémère et à usage unique, et ce qui est vérifié n'est pas une valeur reçue mais une méthode de résolution appliquée par la personne. Il n'y a donc rien à intercepter dans un courriel, ni rien à rejouer plus tard.
FAQ
Le magic link est-il plus sûr qu'un mot de passe ?
Sur certains points oui : rien à mémoriser, rien à réutiliser d'un service à l'autre, pas de base de mots de passe à faire fuiter. Sur d'autres non : la sécurité dépend entièrement de la boîte mail et le jeton reste interceptable et rejouable.
Peut-on l'utiliser comme second facteur ?
C'est déconseillé. Si le premier facteur est déjà un mot de passe, souvent réinitialisable par courriel, les deux facteurs dépendent de la même boîte mail : le critère d'indépendance n'est pas respecté.
Pourquoi certains liens expirent avant même d'être cliqués ?
Le plus souvent à cause des passerelles de sécurité qui analysent automatiquement les liens entrants. Le pré-clic consomme le jeton à usage unique. La parade classique consiste à exiger une confirmation explicite après le clic, plutôt qu'une ouverture de session immédiate.
Convient-il à un usage bancaire ou à une validation de paiement ?
Non. La DSP2 impose deux éléments de catégories distinctes et un lien dynamique entre l'authentification, le montant et le bénéficiaire. Un lien cliqué dans un courriel ne satisfait aucune de ces deux exigences.
Aller plus loin : prouver l'intention plutôt que transporter un secret · l'authentification sans mot de passe · magic link face au spear phishing · identification, authentification, autorisation