Gestion des Sessions

Auris gère les sessions utilisateur via une combinaison de tokens OAuth2 (access token et refresh token) et d’enregistrements de session côté serveur. Ce guide explique le cycle de vie des sessions, comment configurer les politiques de session, comment fonctionne la rotation des tokens et comment révoquer les sessions programmatiquement.

Cycle de Vie des Sessions

Quand un utilisateur s’authentifie via le flux de connexion hébergé, Auris crée ce qui suit :

OAuth Session — Un enregistrement côté serveur qui trace l’état d’authentification, stocké avec un cookie httpOnly sur le domaine de connexion hébergé. Cette session a un TTL de 30 minutes et est utilisée uniquement pendant le flux de connexion.
Access Token — Un JWT de courte durée (défaut : 60 minutes) retourné à ton application. Utilisé comme token Bearer pour authentifier les requêtes API.
Refresh Token — Un token opaque de longue durée (défaut : 30 jours) utilisé pour obtenir de nouveaux access tokens sans demander à l’utilisateur de se reconnecter.
Login Session — Un enregistrement côté serveur dans Auris qui trace la session active, incluant les informations sur l’appareil, l’adresse IP et les méthodes d’authentification utilisées (claims acr/amr).

L’access token est la credential principale que ton application utilise. Quand il expire, le SDK utilise automatiquement le refresh token pour obtenir un nouvel access token (si autoRefresh est activé). Le refresh token lui-même peut être rotaté à chaque utilisation pour une sécurité supplémentaire.

Configurer les Politiques de Session

Les politiques de session contrôlent combien de temps les sessions restent valides et dans quelles conditions elles expirent. Configure-les dans la Console Auris sous Paramètres puis Sécurité.

Paramètres de Durée de Session

Paramètre	Défaut	Description
Durée access token	60 minutes	Combien de temps un access token est valide avant de devoir être renouvelé
Durée refresh token	30 jours	Durée maximale pendant laquelle un refresh token peut être utilisé pour obtenir de nouveaux access tokens
Expiration absolue de session	30 jours	Durée maximale de session indépendamment de l’activité
Timeout d’inactivité	7 jours	Si un utilisateur n’effectue aucune action authentifiée dans cette période, la session est invalidée
Rotation refresh token	Activée	Si activée, chaque utilisation du refresh token émet un nouveau refresh token et invalide l’ancien

Configuration via la Console

Navigue sur Console puis Paramètres puis Sécurité
Dans la section Politiques de Session, modifie les valeurs
Clique Enregistrer

Les modifications prennent effet immédiatement pour les nouvelles sessions. Les sessions existantes continuent avec la politique d’origine jusqu’à expiration.

Configuration via API


curl -X PATCH https://auth.votredomaine.com/api/settings/security \
  -H "Authorization: Bearer $AURIS_ACCESS_TOKEN" \
  -H "x-tenant: votre-tenant-id" \
  -H "Content-Type: application/json" \
  -d '{
    "accessTokenLifetime": 3600,
    "refreshTokenLifetime": 2592000,
    "absoluteSessionExpiry": 2592000,
    "idleTimeout": 604800,
    "refreshTokenRotation": true
  }'

Toutes les durées sont en secondes.

Des durées courtes d’access token (15-30 minutes) combinées avec la rotation des refresh tokens fournissent la meilleure posture de sécurité. Le SDK gère le refresh automatiquement, donc des durées plus courtes n’affectent pas l’expérience utilisateur.

Rotation des Tokens

Comment Fonctionne la Rotation des Refresh Tokens

Quand la rotation des refresh tokens est activée (recommandé), le flux d’échange de tokens fonctionne comme suit :

Ton application envoie le refresh token actuel à l’endpoint token
Auris valide le refresh token et vérifie qu’il n’a pas été révoqué
Auris émet un nouvel access token et un nouveau refresh token
L’ancien refresh token est immédiatement invalidé
Ton application stocke le nouveau refresh token, remplaçant l’ancien


Client                              Auris Token Endpoint
  |                                        |
  |  POST /api/auth/token                  |
  |  grant_type=refresh_token              |
  |  refresh_token=old_RT_abc123           |
  |--------------------------------------->|
  |                                        |  Valide old_RT_abc123
  |                                        |  Invalide old_RT_abc123
  |                                        |  Émet new_AT + new_RT_def456
  |  { access_token, refresh_token }       |
  |<---------------------------------------|
  |                                        |
  |  (old_RT_abc123 est maintenant invalide) |

Pourquoi la Rotation est Importante

Sans rotation, un refresh token volé peut être utilisé indéfiniment (jusqu’à expiration) pour générer de nouveaux access tokens. Avec la rotation :

Chaque refresh token ne peut être utilisé qu’une seule fois
Si un attaquant vole et utilise un refresh token, la prochaine tentative de refresh de l’utilisateur légitime échoue (car le token a déjà été consommé)
Auris détecte ceci comme une anomalie de réutilisation et peut invalider tous les tokens de la famille, forçant une nouvelle authentification

Détection de Réutilisation

Si Auris reçoit un refresh token déjà consommé (indiquant un vol et un replay), il :

Invalide tous les refresh tokens de la même famille de tokens
Enregistre un événement de sécurité dans le log d’audit
L’utilisateur doit s’authentifier à nouveau sur tous les appareils

C’est la défense principale contre le vol de refresh tokens dans les applications browser-based.

Assure-toi que ton application gère le stockage des tokens de façon atomique. Si une réponse de refresh est reçue mais que le nouveau token n’est pas stocké (ex. en raison d’un crash), l’ancien token est déjà invalide et l’utilisateur devra se ré-authentifier. Le SDK gère ceci correctement avec un pattern write-then-ack.

Révocation Programmatique des Sessions

Révoquer une Session Spécifique

Pour révoquer une seule session (ex. quand un utilisateur clique “Déconnecter” sur un appareil spécifique) :


curl -X DELETE https://auth.votredomaine.com/api/sessions/{sessionId} \
  -H "Authorization: Bearer $AURIS_ACCESS_TOKEN" \
  -H "x-tenant: votre-tenant-id"

Ou depuis le SDK :


import { AurisClient } from '@auris/js'
 
const auris = new AurisClient({
  domain: 'auth.votreentreprise.com',
  clientId: 'votre-client-id',
})
 
// Déconnecter la session courante
await auris.logout({ returnTo: 'https://votreapp.com' })

Révoquer Toutes les Sessions d’un Utilisateur

Dans un incident de sécurité (compte compromis, credentials volés), tu pourrais avoir besoin de terminer immédiatement toutes les sessions d’un utilisateur sur tous les appareils :


curl -X POST https://auth.votredomaine.com/api/users/{userId}/revoke-sessions \
  -H "Authorization: Bearer $AURIS_ACCESS_TOKEN" \
  -H "x-tenant: votre-tenant-id"

Cet appel :

Invalide tous les refresh tokens de l’utilisateur
Marque toutes les sessions actives comme révoquées
Les access tokens de l’utilisateur continueront à fonctionner jusqu’à expiration (ce sont des JWT stateless), mais ne peuvent pas être renouvelés

Pour invalider immédiatement les access tokens aussi, ton resource server doit vérifier l’état de la session à chaque requête au lieu de s’appuyer uniquement sur l’expiration du JWT. Le middleware @auris/nextjs fait ceci automatiquement via l’appel verifySessionActive().

Forcer la Ré-authentification

Pour demander à un utilisateur de se ré-authentifier à la prochaine interaction sans terminer les sessions existantes :


curl -X POST https://auth.votredomaine.com/api/users/{userId}/force-reauth \
  -H "Authorization: Bearer $AURIS_ACCESS_TOKEN" \
  -H "x-tenant: votre-tenant-id"

Ceci invalide tous les refresh tokens mais permet aux access tokens actuels de compléter les requêtes en cours. La prochaine fois que le SDK tente un refresh de token, il échouera et redirigera l’utilisateur vers la page de connexion.

Gestion des Sessions Multi-Appareils

Auris trace les sessions par appareil, permettant aux utilisateurs et aux administrateurs de visualiser et gérer les sessions actives sur tous les appareils.

Lister les Sessions Actives

Les utilisateurs peuvent visualiser leurs propres sessions :


curl https://auth.votredomaine.com/api/user/sessions \
  -H "Authorization: Bearer $AURIS_ACCESS_TOKEN" \
  -H "x-tenant: votre-tenant-id"

Réponse :


{
  "ok": true,
  "data": [
    {
      "id": "sess_abc123",
      "deviceInfo": "Chrome 120 sur macOS",
      "ipAddress": "203.0.113.42",
      "location": "Paris, France",
      "lastActiveAt": "2026-01-15T14:30:00Z",
      "createdAt": "2026-01-10T09:00:00Z",
      "isCurrent": true
    },
    {
      "id": "sess_def456",
      "deviceInfo": "Safari sur iPhone 15",
      "ipAddress": "198.51.100.17",
      "location": "Lyon, France",
      "lastActiveAt": "2026-01-14T18:00:00Z",
      "createdAt": "2026-01-12T11:00:00Z",
      "isCurrent": false
    }
  ]
}

Révoquer la Session d’un Appareil Spécifique

Un utilisateur peut révoquer n’importe quelle session qui n’est pas la session courante :


curl -X DELETE https://auth.votredomaine.com/api/user/sessions/sess_def456 \
  -H "Authorization: Bearer $AURIS_ACCESS_TOKEN" \
  -H "x-tenant: votre-tenant-id"

Gestion des Sessions depuis l’Admin

Les administrateurs peuvent visualiser et révoquer les sessions pour n’importe quel utilisateur dans la Console :

Navigue sur Utilisateurs et sélectionne l’utilisateur
Ouvre l’onglet Sessions
Visualise toutes les sessions actives avec appareil, IP, localisation et dernière activité
Clique Révoquer sur les sessions individuelles ou Tout Révoquer pour terminer toutes les sessions

Les admins peuvent également y accéder via API :


# Lister toutes les sessions d'un utilisateur (admin)
curl https://auth.votredomaine.com/api/admin/sessions?userId={userId} \
  -H "Authorization: Bearer $AURIS_ACCESS_TOKEN" \
  -H "x-tenant: votre-tenant-id"
 
# Révoquer une session spécifique (admin)
curl -X DELETE https://auth.votredomaine.com/api/admin/sessions/{sessionId} \
  -H "Authorization: Bearer $AURIS_ACCESS_TOKEN" \
  -H "x-tenant: votre-tenant-id"

Bonnes Pratiques pour la Sécurité des Sessions

Utilise des durées courtes pour les access tokens. Les access tokens sont stateless et ne peuvent pas être révoqués individuellement. Garde-les courts (15-60 minutes) pour que la révocation soit effective rapidement quand les refresh tokens sont invalidés.

Active la rotation des refresh tokens. C’est la défense unique la plus efficace contre le vol de tokens. Auris l’active par défaut — ne la désactive pas sauf si tu as une raison technique spécifique.

Définis une expiration absolue de session raisonnable. Même avec la rotation des refresh tokens, les sessions devraient avoir une limite supérieure. Pour la plupart des applications, 30 jours est un bon défaut. Pour les applications haute sécurité (bancaire, santé), considère 1-7 jours.

Configure le timeout d’inactivité. Les utilisateurs qui cessent d’utiliser l’application devraient être déconnectés automatiquement. Un timeout d’inactivité de 7 jours équilibre sécurité et commodité pour la plupart des cas d’usage.

Vérifie les sessions côté serveur pour les opérations sensibles. Pour des actions comme changer l’e-mail, activer/désactiver la MFA ou initier des transactions financières, appelle l’endpoint de vérification de session Auris pour confirmer que la session est toujours active et n’a pas été révoquée :


import { getSession } from '@auris/nextjs/server'
 
export async function transferFunds(req: Request) {
  const session = await getSession()
  if (!session) {
    return Response.json({ error: 'Session expirée' }, { status: 401 })
  }
 
  // La session est valide et active — continuer
}

Surveille les événements de session. Abonne-toi aux événements webhook login.succeeded et user.session_revoked pour tracer la création et la terminaison des sessions dans ton système d’audit.

Guides Associés

Connexion Hébergée (PKCE) — Comment les tokens sont émis pendant le flux de connexion
Authentification Multi-Facteur — Ajouter un second facteur à la création de session
Protection contre les Attaques — Blocage brute-force et détection de connexions suspectes
Limitation de Débit — Limites de débit API sur les endpoints d’authentification