L'authentification moderne : passkeys, OIDC, sessions - la vraie liste courte

In plain terms

En 2026, la « bonne » façon d'authentifier une application web dépend de deux questions : (1) êtes-vous une app B2C grand public, ou du SaaS B2B ? (2) êtes-vous prêts à opérer votre propre IdP, ou vous en remettez-vous à un provider ? Les patterns du milieu 2020s (JWT stateless + refresh dans localStorage) sont dépassés - pour de bonnes raisons.

L'affaire

Le fil HN reprend la discussion classique et arrive à une convergence intéressante : pour la plupart des applis, la pile pragmatique 2026 est :

1. Session server-side chiffrée en cookie HttpOnly + SameSite=Lax pour l'état d'authentification. Fini le JWT stocké côté client.
2. OIDC (Google/Apple/GitHub) pour l'onboarding sans mot de passe.
3. Passkeys (WebAuthn) pour la seconde étape ou en remplacement complet du mot de passe. C'est enfin adopté partout (iOS 17+, Android 13+, tous navigateurs).
4. Rotation courte de la session server-side (~1h) + refresh long (~14 j) via cookie séparé.
5. Pas de JWT côté client, sauf si vous avez du vrai stateless multi-tenant à faire.

Ce qui a changé, structurellement, c'est trois choses. Un : la fin de localStorage pour les tokens sensibles (XSS = compromission totale, il n'y a plus de débat). Deux : la maturité des passkeys - l'adoption grand public dépasse maintenant le seuil critique dans les principaux écosystèmes (Google, Apple, Microsoft ont tous déployé), même si aucun n'a publié de chiffre détaillé récent. Trois : les IdP hébergés (Clerk, WorkOS, Auth0) offrent maintenant une couverture SSO/SCIM/passkeys clé en main qu'aucune équipe de moins de 5 personnes n'a intérêt à réimplémenter.

Under the hood

• Cookie session : Secure; HttpOnly; SameSite=Lax; __Host- prefix. Rotation à chaque escalade de privilège.
• CSRF : SameSite=Lax couvre 95% des cas ; ajouter un token CSRF sur les mutations sensibles reste la ceinture.
• PKCE obligatoire sur tous les flows OAuth publics (SPA, mobile).
• Piège fréquent : mettre le passkey en 2FA "obligatoire" trop tôt - perte de compte si l'utilisateur n'a qu'un seul device.
• Faille en vogue : les extensions navigateur qui lisent la mémoire d'une SPA - argument supplémentaire pour ne rien mettre dans localStorage.

So what

Trois takeaways. Un : si vous démarrez en 2026, prenez un provider (Clerk, WorkOS, Stack Auth) sauf raison réglementaire précise. Le temps d'ingénierie économisé va au produit. Deux : si vous avez une pile JWT-in-localStorage héritée, planifiez la migration vers session cookie - c'est un travail de sécurité prioritaire, pas cosmétique. Trois : les passkeys sont prêtes ; à activer en option maintenant, et à imposer d'ici 2027 en enterprise. À surveiller : la standardisation des passkeys inter-plateformes (le vrai frein B2B).