Sessions & Rotation Token
Quand un utilisateur se connecte à une application basée sur Auris, le système crée une session. Cette session est l’enregistrement autoritatif de l’état authentifié de l’utilisateur. Comprendre comment fonctionnent les sessions, comment les tokens rotatent et comment Auris détecte le vol de tokens est essentiel pour construire des applications sécurisées.
Qu’est-ce qu’une Session dans Auris ?
Une session dans Auris est un enregistrement côté serveur stocké dans la base de données (via Prisma), pas un cookie ou token côté client. Chaque session contient :
| Champ | Description |
|---|---|
id | Identifiant unique de la session |
userId | L’utilisateur authentifié |
sessionToken | Token opaque stocké dans un cookie httpOnly sur le client |
accessToken | L’access token (JWT) émis le plus récemment |
refreshToken | Le refresh token (chaîne opaque) émis le plus récemment |
tokenFamily | Identifiant reliant tous les refresh tokens dans la chaîne de rotation de cette session |
createdAt | Quand la session a été créée (utilisé pour l’expiration absolue) |
lastActiveAt | Quand la session a été utilisée pour la dernière fois (utilisé pour l’expiration sliding) |
expiresAt | Quand la session expire |
ipAddress | Adresse IP du login original |
userAgent | Identifiant browser/appareil du login original |
acr | Authentication Context Class Reference (le niveau de force de l’authentification) |
amr | Authentication Methods Reference (quels facteurs ont été utilisés : password, otp, webauthn) |
La distinction clé : les sessions Auris sont server-authoritative. Le serveur sait toujours quelles sessions existent, lesquelles sont actives et peut révoquer n’importe quelle session instantanément. On ne se fie pas uniquement à l’expiration du token pour la terminaison de session.
Cycle de Vie de la Session
Création de Session
Quand l’authentification réussit (après tous les facteurs incluant MFA, vérifications de risque adaptatif et hooks de l’Actions Engine), Auris :
- Crée un enregistrement
OAuthSessiondans la base de données - Génère un
sessionTokenaléatoire et le définit comme cookiehttpOnly(TTL 30 minutes, renouvelé à chaque utilisation) - Émet un access token (JWT signé) avec les claims utilisateur, rôles et custom claims
- Émet un refresh token (chaîne opaque avec préfixe
rt_) - Assigne un identifiant
tokenFamilyreliant tous les futurs refresh tokens dans cette session
Utilisation Active
Durant la durée active de la session, le client envoie l’access token à chaque requête API. Le resource server valide la signature JWT localement (via JWKS) sans contacter Auris. Aucune lookup dans la base de données n’a lieu pour la validation de l’access token, ce qui maintient la latence faible.
Rafraîchissement
Quand l’access token expire, le client envoie le refresh token à l’endpoint token. Auris :
- Recherche le refresh token dans la base de données
- Valide qu’il n’a pas déjà été utilisé (vérification de rotation)
- Valide que la session n’a pas expiré (vérification absolue et sliding)
- Invalide l’ancien refresh token (le marque comme utilisé)
- Émet un nouvel access token et un nouveau refresh token
- Met à jour
lastActiveAtsur la session (réinitialise la fenêtre sliding)
Terminaison
Les sessions se terminent à travers plusieurs mécanismes :
| Mécanisme | Quand ça Arrive | Effet |
|---|---|---|
| Logout explicite | L’utilisateur clique “Se déconnecter” | Session supprimée, tous les tokens pour cette session invalidés |
| Expiration sliding | Aucun rafraîchissement dans la fenêtre d’inactivité | La session expire |
| Expiration absolue | La session est active depuis plus du maximum absolu | La session expire indépendamment de l’activité |
| Révocation admin | L’admin révoque la session depuis la Console | Session supprimée immédiatement |
| Détection de réutilisation | Un refresh token déjà utilisé est présenté | Toute la famille de tokens est révoquée |
| Action de compte | Utilisateur désactivé, supprimé ou mot de passe changé | Toutes les sessions pour l’utilisateur sont révoquées |
Rotation du Refresh Token
La rotation du refresh token est un mécanisme de sécurité dans lequel chaque rafraîchissement de token réussi invalide l’ancien refresh token et en émet un nouveau. Auris implémente la rotation par défaut sans possibilité de la désactiver.
Pourquoi Faire Pivoter ?
Sans rotation, un refresh token volé reste valide jusqu’à son expiration naturelle (7 jours par défaut). L’attaquant peut l’utiliser pour obtenir de nouveaux access tokens indéfiniment dans cette fenêtre, même si l’utilisateur légitime continue d’utiliser l’application.
Avec la rotation, un refresh token volé ne peut être utilisé qu’une seule fois. Si l’utilisateur légitime rafraîchit en premier (ce qui est le cas commun), le token volé devient invalide. Si l’attaquant rafraîchit en premier, la tentative de rafraîchissement suivante de l’utilisateur légitime déclenche la détection de réutilisation.
Familles de Tokens
Chaque refresh token dans Auris est associé à un tokenFamily — un identifiant reliant tous les refresh tokens dans une seule chaîne de session. Quand une réutilisation de refresh token est détectée :
- Auris vérifie quelle session est propriétaire du token réutilisé
- Identifie la famille de tokens pour cette session
- Révoque tous les tokens dans cette famille (toute la session)
- La révocation empêche l’attaquant d’utiliser n’importe quel token précédent dans la chaîne
Expiration Absolue vs. Sliding
Auris applique deux types d’expiration à chaque session :
Expiration Absolue : La session expire après un maximum absolu (défaut : 24 heures) depuis sa création, indépendamment de l’activité.
Expiration Sliding (Inactivité) : La session expire après une période d’inactivité (défaut : 1 heure). Chaque fois qu’un rafraîchissement est effectué, la fenêtre sliding se réinitialise.
La session expire quand la première des deux conditions est atteinte. Cet équilibre garantit que :
- Les utilisateurs actifs restent connectés sans devoir se ré-authentifier fréquemment
- Les sessions abandonnées (aucune activité) expirent de manière opportune
- Il existe une garantie temporelle absolue pour la sécurité
Sessions Multi-Dispositifs
Chaque login depuis un appareil différent crée une session séparée. Par défaut, Auris autorise jusqu’à 5 sessions concurrentes par utilisateur.
Quand la limite est atteinte, le login depuis un nouvel appareil révoque la session active la plus ancienne.
Voir les Sessions Actives
Les utilisateurs peuvent voir et gérer leurs sessions actives via ton application en utilisant les API de gestion des sessions. Le champ userAgent permet d’afficher “iPhone” ou “Chrome sur Windows” pour aider les utilisateurs à identifier les sessions non reconnues.
Concepts Associés
- Les Tokens Expliqués — Ce que sont les access tokens, refresh tokens et ID tokens
- OAuth 2.0 & OIDC — Comment les tokens sont émis
- Gestion des Sessions — Voir et révoquer les sessions dans la Console
- Paramètres de Sécurité — Configurer les policies de session