Les passkeys ne suffisent pas : mettez en production des sessions liées à l’appareil en 90 jours

Les passkeys ont éliminé l’essentiel du phishing de mots de passe. Les attaquants se sont adaptés. Ils ont cessé de viser votre formulaire de connexion et se sont mis à voler ce que vous jugez plus fiable que les mots de passe : des jetons de session longue durée. Chrome déploie désormais des sessions liées à l’appareil, et OAuth dispose enfin d’une approche praticable de la preuve de possession (PoP). Si vous ne planifiez pas cela dans les 90 jours, vous budgétez déjà des incidents de prise de contrôle de comptes.

Ce qui vient de changer (et pourquoi c’est important)

Deux signaux sont arrivés en même temps. D’abord, Chrome a commencé à adopter ce qu’il appelle des sessions liées à l’appareil (largement présentées comme la défense au niveau navigateur la plus robuste contre les prises de contrôle de comptes). En clair : une clé gérée par le navigateur lie une session à un appareil précis pour qu’un cookie volé ne puisse pas être rejoué ailleurs. Ensuite, de nouvelles recherches ont mis en lumière des pièges dans les déploiements passkeys réels — ingénierie sociale astucieuse et failles de récupération qui contournent complètement WebAuthn. Ensemble, cela confirme ce que votre file d’incidents sait déjà : les passkeys durcissent l’étape 1, mais ce sont les jetons qui décident de l’issue.

Rien de tout cela n’est théorique. Les kits de phishing par proxy inverse (Evilginx et consorts) et les infostealers de commodité ciblent les cookies de session précisément parce qu’ils contournent le 2FA et les passkeys. Demandez à n’importe quel SaaS à grande échelle : la réutilisation de sessions volées dépasse très largement le phishing classique par mot de passe. Les passkeys ne sont pas l’aboutissement ; ce sont les sessions liées à l’appareil qui le sont.

Mettez à jour votre modèle de menaces pour 2026

• Comportement principal de l’adversaire : Rejeu de sessions et de jetons d’actualisation volés, obtenus via malware, proxys inverses ou SDK tiers mal configurés. Ils évitent complètement votre mur d’authentification.
• Vos zones de faiblesse : Sessions de longue durée, jetons d’actualisation utilisables depuis n’importe quel appareil, rotation laxiste, et parcours de récupération (flux support email/SMS) qui émettent de nouvelles sessions agnostiques de l’appareil.
• Pourquoi maintenant : Les sessions liées à l’appareil de Chrome commencent à combler le trou de rejeu côté client. Côté serveur, DPoP d’OAuth vous offre dès aujourd’hui un moyen interopérable de lier les jetons à une clé par appareil. Inutile d’attendre que les fonctionnalités navigateur mûrissent.

Un cadre de décision : quoi déployer en premier

Traitez cela comme un problème d’ordonnancement, pas un débat de standards. Utilisez votre mix de trafic et votre profil de risque pour prioriser l’ordre.

• Mix de trafic : Si 55–70 % de vos sessions se font sur Chrome, prévoyez de tirer parti des sessions liées à l’appareil dès qu’elles arrivent en stable. Mais ne dépendez pas d’un calendrier fournisseur — déployez la preuve de possession dès maintenant avec DPoP sur tous les navigateurs modernes.
• Surface applicative : Les SPAs et les applis natives peuvent adopter DPoP immédiatement. Les sites rendus côté serveur peuvent tout de même lier l’émission des jetons/refresh à une clé par appareil et exiger la preuve de possession lors du renouvellement.
• Profil client : Clients entreprise derrière des proxys fragiles ? Déployez derrière un feature flag et prévoyez une bascule en douceur. Trafic grand public à l’échelle ? Priorisez une rotation plus rapide et de la télémétrie pour tuer la réutilisation de jetons.
• Récupération et support : Si votre helpdesk peut émettre une session sans liaison à l’appareil, les attaquants le peuvent aussi. Corrigez la récupération en parallèle de tout travail sur les jetons.

Le plan 30‑60‑90

Jour 0–30 : Cessez d’émettre des jetons au porteur que vous ne pouvez pas défendre

• Recenser et raccourcir : Dressez la liste de chaque jeton que vous émettez (cookies de session, jetons API, jetons d’actualisation). Fixez une durée de vie agressive pour les jetons d’accès (10–15 minutes) et imposez la rotation des cookies de session au moins toutes les quelques heures. Utilisez le préfixe __Host‑, HttpOnly, Secure, SameSite=Strict lorsque c’est compatible.
• Supprimez les sessions glissantes sans preuve : Les renouvellements glissants ne doivent se produire que si le client peut prouver qu’il s’agit du même appareil que celui ayant obtenu le jeton initialement.
• Ajoutez de la télémétrie de vol : Journalisez un ID de clé de liaison avec chaque jeton (placeholder pour l’instant), enregistrez l’agent utilisateur, la plateforme et une géolocalisation grossière. Alertez en cas de réutilisation depuis un autre appareil/ASN — même avant la mise en service de la liaison.
• Bloquez les contournements de récupération : Éliminez le SMS comme méthode de récupération pour les comptes à haut risque. Passez aux codes de secours + clé matérielle en repli et exigez une nouvelle étape de liaison d’appareil pour émettre une session post‑récupération.

Jour 31–60 : Liez les jetons aux appareils via DPoP

• Générez une clé par appareil côté client : Pour les SPAs, utilisez WebCrypto pour créer une clé ECDSA P‑256 et la conserver dans IndexedDB. Pour les applis natives, utilisez le trousseau du système avec stockage matériel (Secure Enclave sur iOS/macOS ; StrongBox/TEE sur Android).
• Adoptez DPoP d’OAuth pour l’émission de jetons : Lorsque le client demande un jeton d’accès/d’actualisation, incluez une preuve DPoP signée par la clé de l’appareil. Le serveur lie le jeton émis à cette clé publique. Voir RFC 9449.
• Exigez DPoP sur les requêtes API : Pour les appels authentifiés par un jeton d’accès, exigez un en‑tête DPoP prouvant la possession de la clé liée. Rejetez les jetons présentés sans preuve valide ou avec une méthode/URI non concordants.
• Rotation et attestation : À l’actualisation, exigez une nouvelle preuve. Envisagez une attestation périodique sur mobile (Play Integrity / DeviceCheck) pour les paliers à haut risque. Ne bloquez pas l’avancement faute d’attestation — c’est un signal additionnel.
• Mesurez la surcharge : La vérification ECDSA P‑256 ajoute typiquement ~0,3–0,9 ms de CPU par requête sur un cœur moderne. Prévoyez environ 1–2 KB d’en‑tête supplémentaire par appel. C’est du bruit comparé au coût d’un ticket de support, sans parler d’un incident.

Jour 61–90 : Activez la liaison d’appareil native au navigateur et bouclez la boucle

• Activez les sessions liées à l’appareil là où c’est supporté : Au fur et à mesure du déploiement de la fonctionnalité de Chrome, participez pour vos domaines principaux et faites correspondre la liaison gérée par le navigateur à votre notion côté serveur d’une clé d’appareil. Conservez DPoP comme socle inter‑navigateurs.
• Durcissez les parcours d’actualisation : Tout chemin qui retourne un nouveau jeton doit exiger une preuve de possession. Pas de PoP, pas de jeton. Cela inclut les flows OAuth device code, les échanges PKCE et les émissions de session par le support client.
• Automatisation d’incident : En cas de vol suspecté (jeton vu sans PoP ou avec une nouvelle clé d’appareil), révoquez automatiquement cette famille de jetons, forcez une nouvelle liaison d’appareil et notifiez l’utilisateur. Ajoutez un bouton « Ce n’était pas moi » qui déclenche une revue au niveau du compte.
• Refonte de la récupération : La récupération crée une session à faible risque et courte durée qui ne peut être montée en privilège qu’en réalisant une nouvelle cérémonie WebAuthn ou en produisant la preuve via la clé d’appareil. Pas de saut direct vers une session longue durée et pleinement privilégiée.

Architecture de référence : à quoi ressemble le « bon »

1. Amorçage de la clé d’appareil : À la première connexion (passkey/WebAuthn recommandé), le client génère une paire de clés d’appareil de longue durée (WebCrypto ou trousseau OS). La clé publique et un ID d’appareil aléatoire sont enregistrés auprès de votre service d’auth.
2. Émission de jetons avec PoP : Le client demande des jetons avec une preuve DPoP. Le service d’auth lie les jetons (accès + actualisation + cookie de session) à la clé publique de l’appareil et les retourne. Les cookies restent HttpOnly ; la preuve PoP est envoyée dans un en‑tête.
3. Application côté API : Votre passerelle API valide le jeton et vérifie la signature DPoP par rapport à la clé publique liée, à la méthode et à l’URL. Les discordances, le décalage d’horloge ou la réutilisation d’un jti sont rejetés et signalés.
4. Discipline de rotation : Les jetons d’accès expirent après 10–15 minutes. Les jetons d’actualisation sont à usage unique et tournent à chaque échange. Les cookies de session tournent toutes les quelques heures ou lors d’un changement de privilège. Tous les renouvellements exigent une PoP.
5. Récupération et step‑up : La récupération crée une session limitée, pas un passe‑droit. Toute élévation (facturation, export de données, création de clé API) requiert soit une assertion WebAuthn, soit une PoP via la clé d’appareil stockée.
6. Télémétrie : Stockez et analysez « ID de clé de liaison × numéro d’AS IP × plateforme ». Alertez en cas de rotation soudaine des clés d’appareil pour un utilisateur ou de réutilisation d’une clé de liaison sur de nombreux comptes (automatisation malveillante).

Arbitrages et pièges (à reconnaître dès maintenant)

• Tous les navigateurs ne sont pas prêts : Les sessions liées à l’appareil arriveront de manière inégale. C’est pourquoi DPoP est la base inter‑navigateurs. Gardez des mécanismes de repli, mais ne les laissez pas contourner silencieusement la PoP.
• Proxys d’entreprise et API gateways : Certains middleboxes réécrivent des en‑têtes. Protégez les en‑têtes DPoP de bout en bout (terminaison TLS uniquement à votre edge) et documentez les prérequis pour vos clients entreprise.
• Comptes partagés : Stop au partage. Mettez en place des accès délégués et des clés API à rôles, liées à chaque utilisateur. Si vous y êtes absolument contraints, prenez en charge des liaisons d’appareil séparées par opérateur et limitez les privilèges.
• Performance : La PoP ajoute du calcul cryptographique. Amortissez à l’edge, mettez en cache l’introspection des jetons et préférez ECDSA P‑256 à des courbes plus lourdes. En pratique, la latence ajoutée est sous la milliseconde sur du matériel standard.
• Cycle de vie des clés : Les appareils sont remplacés. Fournissez un flux propre de « retrait de clé d’appareil » et notifiez lors des nouvelles liaisons d’appareil. Limitez la liste des clés d’appareil actives par utilisateur (5–10).
• Légal et confidentialité : Lier à une clé d’appareil n’est pas du device fingerprinting. Vous stockez une clé publique, pas une empreinte canvas. Documentez‑le dans votre notice de confidentialité et donnez visibilité et contrôle aux utilisateurs.

Comment cela s’articule avec les passkeys (et où les équipes se trompent)

Les passkeys prouvent que c’est le bon humain, sur un vrai appareil, au moment de la connexion. Ensuite, le risque se déplace vers les jetons. Échecs courants observés lors des audits :

• Passkey en entrée, bearer en sortie : Les équipes modernisent la connexion en WebAuthn mais émettent encore un cookie au porteur que n’importe quelle machine peut rejouer. Vous avez renforcé la porte d’entrée et laissé le coffre ouvert.
• Angles morts de récupération : Les SMS et liens email émettent des sessions non liées. Utilisez‑les pour amorcer une nouvelle liaison d’appareil, pas pour la contourner.
• Durées d’actualisation trop longues : Des jetons d’actualisation de 30 jours sans PoP sont un cadeau pour les infostealers. Faites tourner à chaque usage ; expirez rapidement les jetons non utilisés.

KPIs que votre board acceptera

• Taux de réutilisation de sessions volées : Ciblez une réduction de 80 % ou plus dans les 90 jours suivant le déploiement, mesurée par des jetons présentés sans PoP valide ou avec une nouvelle liaison d’appareil.
• Temps de révocation : Moins de 60 secondes entre le premier usage suspect et la révocation de toute la famille de jetons.
• Couverture : Pourcentage de sessions actives avec liaison d’appareil appliquée. Atteignez 70 % au jour 60 ; 90 % au jour 120.
• Charge support : Moins de tickets ATO par million de MAU. Attendez‑vous à une légère hausse à court terme en fermant les brèches, puis à une baisse régulière.

Notes d’implémentation par plateforme

• Web (SPA/MPA) : Générez les clés d’appareil avec WebCrypto ; stockez‑les dans IndexedDB ; signez les DPoP avec SubtleCrypto. Pour les MPA, vous pouvez maintenir un « service worker de clé d’appareil » en arrière‑plan pour signer les preuves des POST privilégiés.
• Mobile : Clés adossées au matériel via Keychain (iOS) et Keystore (Android). Utilisez l’attestation quand elle est disponible. Liez les jetons à ces clés ; exigez la PoP à l’actualisation et sur les appels API sensibles.
• Desktop (Electron/Tauri) : Utilisez les APIs de trousseau de l’OS. Empêchez l’export des clés privées. Envisagez le mTLS pour les déploiements entreprise internes.
• Serveurs et CLIs : Pour l’automatisation, utilisez des identifiants client OAuth de courte durée ou des jetons de service à périmètre restreint, liés par PoP. Ne placez jamais de jetons au porteur longue durée dans des secrets de CI.

Stratégie de déploiement : minimiser la casse, maximiser l’impact

• Feature flag par audience : Commencez avec les comptes employés, puis une cohorte de clients à haut risque, puis le reste. Fournissez une interface de gestion des appareils en self‑service avant le basculement large.
• Application progressive : Mode « log‑only » pendant une semaine, puis application souple à l’actualisation, puis application stricte sur tous les endpoints privilégiés.
• Communiquez clairement : Expliquez le changement en langage simple : « Nous lions les sessions à votre appareil pour empêcher le vol de jetons. Vous verrez une invite unique pour enregistrer cet appareil. » Proposez des codes de secours et des étapes de récupération claires.

Pourquoi le nearshore est clé ici

Ce n’est pas un moonshot ; c’est un projet d’ingénierie discipliné avec des critères d’acceptation clairs. Une équipe nearshore focalisée peut le livrer de bout en bout — changements du service d’auth, application à la passerelle, stockage des clés mobile/web, télémétrie et playbooks SOC — pendant que votre équipe cœur continue à livrer le produit. Comptez 6–8 semaines de travail pour un SaaS de taille moyenne (web + mobile), plus deux semaines de déploiement progressif et d’ajustements.

En bref

Les passkeys ont rendu le phishing coûteux. Les sessions liées à l’appareil rendent le vol de jetons non rentable. Combinez la liaison au niveau navigateur dès qu’elle arrive avec DPoP que vous pouvez déployer aujourd’hui, et vous éliminerez la plus grande classe d’ATO sans reconstruire toute votre pile d’auth. S’il ne faut livrer qu’un projet sécurité ce trimestre, faites celui‑ci.

Points clés

• Les passkeys sont nécessaires mais insuffisantes ; les attaquants rejouent des jetons volés pour les contourner.
• Les sessions liées à l’appareil de Chrome et DPoP d’OAuth comblent le trou de rejeu en exigeant une preuve de possession.
• À livrer en 90 jours : raccourcissez les jetons, ajoutez de la télémétrie, implémentez DPoP, puis activez la liaison native navigateur au fil du déploiement.
• Faites appliquer la PoP à chaque actualisation et appel API privilégié ; la récupération doit amorcer une nouvelle liaison d’appareil, pas la contourner.
• Attendez‑vous à une surcharge crypto sous la milliseconde et à une baisse mesurable des incidents ATO en un trimestre.