JWT — le standard incontournable de l'authentification d'API
Les JSON Web Tokens se sont imposés comme la solution privilégiée pour l'authentification sans état (stateless) dans les architectures d'API modernes. Le principe est simple : après une première identification, le serveur délivre un token signé que le client conserve et renvoie à chaque requête. Ce token contient les informations nécessaires à la vérification : identité de l'utilisateur, droits d'accès, date d'expiration.
L'avantage principal réside dans l'absence de requête vers une base de données ou un cache à chaque appel. Le serveur valide la signature à l'aide d'une clé secrète ou d'une clé publique, sans consultation externe. Cette propriété rend les JWT particulièrement adaptés aux architectures microservices ou aux API publiques où la latence doit rester minimale.
La pratique impose cependant des précautions rigoureuses. Le token doit être signé avec un algorithme robuste (HS256 ou RS256), stocké côté client dans un cookie sécurisé avec les flags httpOnly et Secure, jamais dans le localStorage vulnérable aux attaques XSS. La durée de validité ne devrait pas excéder quinze minutes pour un token d'accès, un refresh token à plus longue durée permettant de renouveler la session sans solliciter l'utilisateur.
Les limites des JWT méritent d'être connues. L'impossibilité de révoquer un token avant son expiration — sauf à maintenir une blacklist côté serveur, ce qui annule l'avantage stateless — constitue la critique la plus fréquente. Pour les applications nécessitant un contrôle fin des sessions (changement de mot de passe, blocage de compte), une approche hybride avec stockage partiel en base reste préférable.
OAuth 2.0 et OpenID Connect — l'authentification déléguée
Lorsque votre application doit permettre à ses utilisateurs de se connecter via Google, GitHub ou tout autre fournisseur d'identité tiers, OAuth 2.0 s'impose comme le protocole de référence. Il dissocie le rôle du fournisseur d'identité, qui authentifie l'utilisateur, de celui de l'application cliente, qui consomme l'identité sans manipuler le mot de passe.
OAuth 2.0 définit plusieurs flux selon le type de client. Le plus répandu en 2026 reste l'Authorization Code Flow avec PKCE (Proof Key for Code Exchange), recommandé pour les applications monopages et mobiles. Il garantit que même si le code d'autorisation est intercepté, son échange contre un token d'accès reste impossible sans le secret généré côté client.
OpenID Connect (OIDC) ajoute une couche d'identité au-dessus d'OAuth 2.0. Là où OAuth ne fournit qu'un token d'accès opaque, OIDC délivre un ID Token (au format JWT) contenant des informations structurées sur l'utilisateur : adresse électronique, nom, identifiant unique. Ce mécanisme simplifie considérablement la gestion des comptes : le fournisseur d'identité se charge de la vérification, des tentatives de connexion suspectes, et de la récupération de mot de passe.
En 2026, l'adoption d'OIDC s'est généralisée au point que peu d'applications nouvelles implémentent leur propre système d'authentification de zéro. Des services comme Clerk, Auth0 ou Supabase Auth permettent d'intégrer un flux OIDC complet en quelques lignes de code, avec gestion des sessions, de la multi-factor authentication et des rôles intégrée.
Sessions côté serveur — la solution éprouvée qui résiste au temps
Avant la généralisation des tokens, l'authentification reposait sur des sessions stockées côté serveur : un identifiant aléatoire (session ID) est transmis via un cookie, et le serveur conserve en mémoire ou en base de données l'état complet de la session. Cette approche, parfois jugée dépassée, conserve des avantages décisifs dans certains contextes.
La révocabilité immédiate constitue le premier d'entre eux. Supprimer une session en base de données déconnecte instantanément l'utilisateur. Aucune attente d'expiration de token, aucune blacklist complexe. Pour les applications manipulant des données sensibles — santé, finance, administration — cette capacité de contrôle direct reste irremplaçable.
La simplicité de mise en œuvre plaide également en sa faveur. Pas de gestion de signature, pas d'algorithme de chiffrement, pas de refresh token. Une table de sessions, un cookie sécurisé, et le tour est joué. Les frameworks modernes (Express avec express-session, Django avec ses sessions intégrées, FastAPI avec des middlewares dédiés) offrent des implémentations prêtes à l'emploi, robustes et auditées.
Le passage à l'échelle constitue en revanche le point faible historique des sessions. Dans une architecture distribuée, la session doit être partagée entre tous les serveurs, ce qui implique une couche de cache centralisée (Redis, Memcached) ou une réplication en base de données. Des solutions comme Redis Cluster ou Amazon ElastiCache résolvent ce problème pour la plupart des volumes de trafic, mais ajoutent une complexité d'infrastructure que les JWT permettent d'éviter.
Pour les applications monolithiques ou les équipes de taille modeste, le compromis reste très favorable. Les sessions offrent une sécurité robuste, une gestion fine, et une courbe d'apprentissage bien plus douce que les protocoles OAuth.
Passkeys et WebAuthn — l'authentification sans mot de passe
Les passkeys représentent l'évolution la plus significative de l'authentification depuis l'avènement du mot de passe. Fondés sur le standard WebAuthn (Web Authentication), ils remplacent la saisie d'un mot de passe par une validation biométrique (empreinte, reconnaissance faciale) ou un code PIN, directement gérée par le système d'exploitation de l'appareil.
Le mécanisme repose sur la cryptographie asymétrique. Lors de l'enregistrement, l'appareil génère une paire de clés : la clé privée reste stockée dans l'environnement sécurisé de l'appareil (TEE, Secure Enclave), la clé publique est transmise au serveur. Pour s'authentifier, l'utilisateur déverrouille son appareil, ce qui déclenche une signature numérique vérifiée par le serveur à l'aide de la clé publique stockée. Le mot de passe — et sa vulnérabilité structurelle — disparaît de l'équation.
L'adoption des passkeys connaît une accélération notable en 2026. Apple, Google et Microsoft ont unifié leurs implémentations, permettant la synchronisation des clés privées entre appareils via les gestionnaires de mots de passe intégrés (iCloud Keychain, Google Password Manager). Le support navigateur dépasse désormais 90 % d'après les statistiques d'utilisation, et des bibliothèques comme SimpleWebAuthn ou @passwordless-id/webauthn simplifient l'intégration côté serveur.
Les freins restent pourtant réels. La dépendance à l'écosystème du fournisseur (Apple, Google) pour la synchronisation entre appareils soulève des questions de verrouillage. La gestion des comptes invités ou des appareils partagés n'est pas résolue de manière satisfaisante. En pratique, les passkeys s'intègrent aujourd'hui comme une couche supplémentaire plutôt que comme un remplacement complet — combinés à un flux OAuth 2.0 ou à des sessions classiques, ils réduisent la friction sans créer de point de défaillance.
Choisir la bonne approche pour son projet
Aucune solution universelle n'existe. Le choix dépend de plusieurs facteurs : architecture de l'application, profil des utilisateurs, exigences de sécurité, charge attendue. Voici les critères qui guident ce choix.
Pour une API publique destinée à des développeurs tiers, les JWT restent la solution la plus adaptée. Leur format standardisé, leur indépendance vis-à-vis du serveur d'authentification, et leur compatibilité avec les environnements hétérogènes en font le choix naturel. GitHub, Stripe ou Supabase l'ont démontré.
Pour une application web destinée à des utilisateurs non techniques, une approche par sessions avec OIDC pour la connexion sociale offre le meilleur équilibre entre sécurité et expérience utilisateur. La révocabilité des sessions et la délégation de l'authentification aux grands fournisseurs d'identité réduisent les risques tout en simplifiant le parcours.
Pour une application mobile, l'association d'un flux OAuth 2.0 avec PKCE et de passkeys pour l'authentification secondaire constitue l'état de l'art en 2026. Les utilisateurs bénéficient d'une connexion biométrique rapide, sans compromettre la sécurité du flux d'autorisation.
Enfin, pour les applications internes d'entreprise ou les outils B2B, les sessions côté serveur avec authentification multifacteur restent le standard de référence. La gestion centralisée des accès, la traçabilité et la conformité aux réglementations (RGPD, SOC 2) y sont plus facilement garanties.
Conclusion
L'authentification moderne ne se résume plus à un choix binaire entre sessions et tokens. La palette d'outils disponibles en 2026 — JWT, OAuth 2.0, OIDC, sessions persistantes, passkeys — permet d'assembler des solutions sur mesure, adaptées à chaque contexte. La tendance de fond est à la délégation : confier l'authentification à des services spécialisés (Auth0, Clerk, Supabase Auth) ou à des protocoles standardisés. Dans un environnement où la sécurité des données personnelles est devenue un enjeu concurrentiel, investir dans une architecture d'authentification bien conçue n'est pas une option, mais une nécessité.
La règle à retenir : ne jamais implémenter son propre système d'authentification de zéro. Les protocoles éprouvés et les bibliothèques auditées existent ; les utiliser, c'est éviter des années d'erreurs de sécurité déjà documentées.