Gérer le cycle de session
Conserver une expérience de connexion fluide tout en limitant les risques autour des jetons et de leur rotation.
Scripts & Outils · 2025
Une identité fiable se joue autant dans les cas limites que dans la connexion réussie.
Stack
IdP
Typologie
2FA
Facteur
RBAC
Accès
Redis
Sessions
Le problème — 01
Un système d’auth n’est pas « terminé » quand la connexion marche — il l’est quand les cas limites restent sous contrôle.
Ce système d’authentification explore les briques d’un fournisseur d’identité : sessions, rotation de refresh tokens, second facteur et rôles.
L’enjeu est de concevoir des mécanismes sûrs tout en gardant le système explicable et observable lorsqu’un cas d’exception survient.
L'approche — 02
Sessions, rotation de tokens, 2FA et RBAC comme pièces distinctes — chacune avec un contrat clair — plutôt qu’un monolithe opaque.
Expiration, révocation, échec 2FA : ces chemins doivent être aussi explicites que la connexion réussie.
Un système d’authentification ne se juge pas sur la connexion réussie, mais sur ce qu’il fait des cas limites.
Défis & décisions — 03
Conserver une expérience de connexion fluide tout en limitant les risques autour des jetons et de leur rotation.
Faire cohabiter RBAC et authentification forte sans rendre les autorisations imprévisibles.
Résultat — 04
Un socle d’identité personnel qui explore sessions, rotation de tokens, 2FA et RBAC — conçu pour être compris autant que pour être sûr.
Ce que j'en retiens — 05
La sécurité d’un IdP se juge sur les échecs et les expirations, pas sur le happy path.
RBAC et 2FA ne s’additionnent pas mécaniquement : leur composition doit rester prévisible pour l’utilisateur comme pour le développeur.
Projet suivant
TakeSeat
Startup / SaaS
Et après
Un projet, une opportunité de stage ou simplement l'envie d'échanger ? Ma boîte de réception est ouverte.
Démarrer une conversation