Sessioni & Rotazione Token
Quando un utente accede a un’applicazione basata su Auris, il sistema crea una sessione. Questa sessione è il record autorevole dello stato autenticato dell’utente. Capire come funzionano le sessioni, come i token ruotano e come Auris rileva il furto di token è essenziale per costruire applicazioni sicure.
Cos’è una Sessione in Auris?
Una sessione in Auris è un record lato server archiviato nel database (tramite Prisma), non un cookie o token lato client. Ogni sessione contiene:
| Campo | Descrizione |
|---|---|
id | Identificatore univoco della sessione |
userId | L’utente autenticato |
sessionToken | Token opaco archiviato in un cookie httpOnly sul client |
accessToken | Il token di accesso (JWT) emesso più di recente |
refreshToken | Il refresh token (stringa opaca) emesso più di recente |
tokenFamily | Identificatore che collega tutti i refresh token nella catena di rotazione di questa sessione |
createdAt | Quando la sessione è stata creata (usato per la scadenza assoluta) |
lastActiveAt | Quando la sessione è stata usata l’ultima volta (usato per la scadenza sliding) |
expiresAt | Quando la sessione scade |
ipAddress | Indirizzo IP dal login originale |
userAgent | Identificatore browser/dispositivo dal login originale |
acr | Authentication Context Class Reference (il livello di forza dell’autenticazione) |
amr | Authentication Methods Reference (quali fattori sono stati usati: password, otp, webauthn) |
La distinzione chiave: le sessioni Auris sono server-authoritative. Il server sa sempre quali sessioni esistono, quali sono attive e può revocare qualsiasi sessione istantaneamente. Non si fa affidamento solo sulla scadenza del token per la terminazione della sessione.
Ciclo di Vita della Sessione
Creazione della Sessione
Quando l’autenticazione ha successo (dopo tutti i fattori inclusi MFA, controlli di rischio adattivi e hook dell’Actions Engine), Auris:
- Crea un record
OAuthSessionnel database - Genera un
sessionTokencasuale e lo imposta come cookiehttpOnly(TTL 30 minuti, rinnovato ad ogni uso) - Emette un token di accesso (JWT firmato) con i claim dell’utente, i ruoli e i custom claim
- Emette un refresh token (stringa opaca con prefisso
rt_) - Assegna un identificatore
tokenFamilyche collega tutti i futuri refresh token in questa sessione
Uso Attivo
Durante la durata attiva della sessione, il client invia il token di accesso su ogni richiesta API. Il resource server valida la firma JWT localmente (tramite JWKS) senza contattare Auris. Non avviene alcuna lookup nel database per la validazione del token di accesso, il che mantiene bassa la latenza.
Refresh
Quando il token di accesso scade, il client invia il refresh token all’endpoint token. Auris:
- Cerca il refresh token nel database
- Valida che non sia già stato usato (controllo rotazione)
- Valida che la sessione non sia scaduta (controllo assoluto e sliding)
- Invalida il vecchio refresh token (lo contrassegna come usato)
- Emette un nuovo token di accesso e un nuovo refresh token
- Aggiorna
lastActiveAtsulla sessione (azzera la finestra sliding)
Terminazione
Le sessioni terminano attraverso diversi meccanismi:
| Meccanismo | Quando Accade | Effetto |
|---|---|---|
| Logout esplicito | L’utente clicca “Disconnetti” | Sessione eliminata, tutti i token per questa sessione invalidati |
| Scadenza sliding | Nessun refresh entro la finestra di inattività | La sessione scade |
| Scadenza assoluta | La sessione è viva da più del massimo assoluto | La sessione scade indipendentemente dall’attività |
| Revoca admin | L’admin revoca la sessione dalla Console | Sessione eliminata immediatamente |
| Rilevamento riutilizzo | Viene presentato un refresh token già usato | Intera famiglia di token revocata |
| Azione account | Utente disabilitato, eliminato o password cambiata | Tutte le sessioni per l’utente vengono revocate |
Rotazione del Refresh Token
La rotazione del refresh token è un meccanismo di sicurezza in cui ogni refresh di token riuscito invalida il vecchio refresh token e ne emette uno nuovo. Auris implementa la rotazione di default senza possibilità di disabilitarla.
Perché Ruotare?
Senza rotazione, un refresh token rubato rimane valido fino alla sua scadenza naturale (7 giorni per default). L’attaccante può usarlo per ottenere nuovi token di accesso indefinitamente in quella finestra, anche se l’utente legittimo continua a usare l’applicazione.
Con la rotazione, un refresh token rubato può essere usato solo una volta. Se l’utente legittimo fa il refresh prima (che è il caso comune), il token rubato diventa non valido. Se l’attaccante fa il refresh prima, il successivo tentativo di refresh dell’utente legittimo attiva il rilevamento del riutilizzo.
Famiglie di Token
Ogni refresh token in Auris è associato a un tokenFamily — un identificatore che collega tutti i refresh token in una singola catena di sessione. Quando viene rilevato il riutilizzo di un refresh token:
- Auris controlla quale sessione è proprietaria del token riutilizzato
- Identifica la famiglia di token per quella sessione
- Revoca tutti i token in quella famiglia (l’intera sessione)
- La revoca impedisce all’attaccante di usare qualsiasi token precedente nella catena
Scadenza Assoluta vs. Sliding
Auris applica due tipi di scadenza a ogni sessione:
Scadenza Assoluta: La sessione scade dopo un massimo assoluto (default: 24 ore) dalla sua creazione, indipendentemente dall’attività.
Scadenza Sliding (Inattività): La sessione scade dopo un periodo di inattività (default: 1 ora). Ogni volta che viene effettuato un refresh, la finestra sliding si azzera.
La sessione scade quando si raggiunge la prima delle due condizioni. Questo bilanciamento garantisce che:
- Gli utenti attivi rimangono connessi senza dover ri-autenticarsi frequentemente
- Le sessioni abbandonate (nessuna attività) scadono in modo tempestivo
- Esiste una garanzia temporale assoluta per la sicurezza
Sessioni Multi-Dispositivo
Ogni login da un dispositivo diverso crea una sessione separata. Per default, Auris consente fino a 5 sessioni concorrenti per utente.
Quando viene raggiunto il limite, il login da un nuovo dispositivo revoca la sessione attiva più vecchia.
Viewing Active Sessions
Gli utenti possono visualizzare e gestire le proprie sessioni attive tramite la tua applicazione usando le API di gestione delle sessioni. Il campo userAgent consente di mostrare “iPhone” o “Chrome su Windows” per aiutare gli utenti a identificare le sessioni non riconosciute.
Concetti Correlati
- I Token Spiegati — Cosa sono i token di accesso, i refresh token e gli ID token
- OAuth 2.0 & OIDC — Come vengono emessi i token
- Gestione Sessioni — Visualizza e revoca le sessioni nella Console
- Impostazioni Sicurezza — Configura le policy di sessione