Les deux tokens existent pour résoudre un conflit direct : un access token doit être envoyé à chaque requête (il est donc très exposé), mais vous voulez aussi des sessions qui durent longtemps sans forcer des connexions fréquentes. Vous ne pouvez pas avoir les deux en toute sécurité dans un seul token — alors vous divisez la tâche.
Authorization à chaque appel API. Comme il est transmis constamment, une fuite est probable ; le garder court signifie qu'un token volé expire presque immédiatement.Login ──▶ access (15m) + refresh (30d)
Every API call ──▶ send access
Access expired ──▶ send refresh ──▶ new access (+ rotated refresh)
| Un access token à longue durée de vie | Access + refresh | |
|---|---|---|
| Exposition | Envoyé à chaque requête, vit longtemps → grande fenêtre de vol | Access à courte durée ; refresh rarement envoyé |
| Révocation | Difficile (un JWT stateless ne peut être désémis) | Révoquer le refresh token ; l'access meurt en quelques minutes |
| UX | Reconnexion fréquente si court | Reste connecté sans ressaisir les identifiants |
| Rayon d'impact d'une fuite | Grand | Petit (l'access expire vite) |
httpOnly, hors de portée du XSS.C'est le design d'authentification moderne standard, et les recruteurs le posent pour voir si vous comprenez le pourquoi, pas seulement le comment. L'idée clé est le compromis : statelessness et exposition courte (access) contre sessions longues et révocabilité (refresh). Se tromper — un access token à longue durée de vie, pas de rotation, un refresh stocké dans localStorage — transforme un seul token qui fuite en une compromission de compte à long terme. Nommer la division et ce que chaque token vous apporte, c'est ce qu'un ingénieur soucieux de la sécurité est censé savoir.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don