Comment gérez-vous les durées de vie des sessions et des jetons (access vs refresh, rotation) ?
Réponse courte
Gardez les jetons d'accès à courte durée de vie (quelques minutes) pour qu'un jeton volé expire vite, et utilisez des jetons de rafraîchissement à plus longue durée pour obtenir de nouveaux jetons d'accès sans re-solliciter l'utilisateur. Faites tourner les refresh tokens à chaque utilisation et détectez la réutilisation d'un jeton consommé comme un signal de vol, en révoquant la chaîne. L'objectif est d'équilibrer la limitation de la fenêtre d'un jeton compromis sans forcer les utilisateurs à se réauthentifier sans cesse.
Les jetons et les sessions sont des identifiants au porteur : quiconque en détient un est traité comme l'utilisateur. Leur durée de vie est donc un levier de sécurité direct, et l'entretien veut entendre que vous comprenez ce compromis.
Jetons d'accès vs jetons de rafraîchissement
- Jeton d'accès — présenté à chaque appel d'API, souvent un JWT sans état. Rendez-le à courte durée de vie (généralement 5 à 15 minutes). S'il est volé, la fenêtre de l'attaquant est étroite, et parce qu'il est sans état vous ne pouvez généralement pas le révoquer en cours de vie — l'expiration courte est l'atténuation.
- Jeton de rafraîchissement — à plus longue durée de vie, gardé plus précieusement, utilisé uniquement pour émettre de nouveaux jetons d'accès quand l'ancien expire. Cela maintient l'utilisateur connecté sans le re-solliciter, tandis que le secret de grande valeur est échangé rarement et via le canal arrière.
Rotation des jetons de rafraîchissement
La bonne pratique (RFC 9700) consiste en des jetons de rafraîchissement à usage unique avec rotation : chaque rafraîchissement renvoie un nouveau refresh token et invalide l'ancien. Le bénéfice clé est la détection de vol — si un refresh token déjà utilisé (désormais invalidé) est présenté à nouveau, cela signifie que deux parties en détiennent des copies. Le serveur le traite comme une compromission et révoque toute la famille de jetons, déconnectant l'utilisateur partout.
Sessions : timeout d'inactivité vs absolu
Pour les sessions côté serveur, combinez un timeout d'inactivité (expiration après inactivité) avec un timeout absolu (plafond strict quelle que soit l'activité). Liez les sessions à un cookie sécurisé, HttpOnly, SameSite, et régénérez l'identifiant de session lors d'un changement de privilège (par exemple après connexion) pour contrer la fixation.
Pièges de stockage
Dans les navigateurs, préférez les cookies HttpOnly à localStorage, lisible par n'importe quelle charge XSS. Proposez toujours une déconnexion explicite et une révocation côté serveur pour l'identifiant à longue durée de vie.
Ce que recherchent les recruteurs : vous opposez les durées de vie courtes (access) / plus longues (refresh), vous savez expliquer comment la rotation transforme la réutilisation d'un refresh en alarme de vol, et vous savez que les JWT sans état échangent la révocabilité contre une expiration courte.
Questions de suivi probables
- Comment la rotation des refresh tokens détecte-t-elle un jeton volé ?
- Pourquoi ne peut-on pas simplement révoquer un jeton d'accès JWT sans état en cours de vie ?
- Où les jetons devraient-ils être stockés dans un navigateur, et pourquoi pas dans localStorage ?