Implementazione del logout e della gestione delle sessioni OIDC: una guida completa

Cos'è la gestione delle sessioni OIDC#

OpenID Connect (OIDC) è un semplice strato d'identità costruito sopra il protocollo OAuth 2.0. Consente ai client di verificare l'identità dell'utente finale basandosi sull'autenticazione effettuata dal server di autorizzazione, oltre a ottenere informazioni di profilo di base sull'utente finale in modo interoperabile e simile a REST.

OIDC è progettato per essere facile da usare e implementare, con un focus sulla semplicità e flessibilità. È ampiamente utilizzato per il single sign-on (SSO) e la verifica dell'identità nelle applicazioni web, nelle app mobili e nelle API.

Comprendere lo stato di autenticazione e la gestione delle sessioni in OIDC è cruciale. Questo articolo spiega come le sessioni OIDC e lo stato di autenticazione dell'utente siano gestiti nel contesto delle interazioni tra il Fornitore di identità (IdP) e la Parte Affidabile (RP) o il Fornitore di Servizi (SP).

Questo articolo include diversi termini chiave.

• Fornitore di identità (IdP): Il servizio che memorizza e autentica le identità degli utenti.
• Fornitore di Servizi (SP) o Parte Affidabile (RP): Un'applicazione web o un servizio che fornisce servizi agli utenti e si affida all'IdP per l'autenticazione degli utenti.
• Sessione di accesso o Sessione di autenticazione: La sessione che viene stabilita quando un utente accede all'IdP.
• Grant: Le informazioni centralizzate di autenticazione e autorizzazione dell'utente che vengono generate e gestite dall'IdP.
• Single Sign-On (SSO): Un servizio di sessione e autenticazione utente che consente a un utente di utilizzare un set di credenziali di accesso (es. nome e password) per accedere a più applicazioni.

Come funziona il flusso di autenticazione OIDC#

Per comprendere meglio la gestione delle sessioni OIDC e dello stato di autenticazione dell'utente, diamo un'occhiata al flusso di autenticazione OIDC per un'applicazione web:

1. L'utente accede all'applicazione web (RP).
2. L'RP reindirizza l'utente al provider OIDC (IdP) per l'autenticazione.
3. Il provider OIDC verifica lo stato della sessione di accesso dell'utente. Se non esiste una sessione o la sessione è scaduta, l'utente viene richiesto di accedere.
4. L'utente interagisce con la pagina di accesso per autenticarsi.
5. La pagina di accesso invia il risultato dell'interazione al provider OIDC.
6. Il provider OIDC crea una nuova sessione di accesso e un grant di autenticazione per l'utente.
7. Il provider OIDC reindirizza l'utente al RP con un codice di autenticazione (flusso del Codice di Autorizzazione).
8. L'RP riceve il codice di autenticazione e lo scambia per i token per accedere alle informazioni dell'utente.

Cos'è la gestione delle sessioni di accesso RP#

Una sessione di accesso viene stabilita quando un utente effettua il login all'IdP. Questa sessione viene utilizzata per tracciare lo stato di autenticazione dell'utente all'IdP. La sessione include tipicamente informazioni come l'identità dell'utente, l'orario di autenticazione e il tempo di scadenza della sessione. Viene creata quando l'utente effettua il primo accesso e viene mantenuta fino a quando l'utente esce o la sessione scade.

Un cookie di sessione sarà impostato in modo sicuro nel browser dell'utente per mantenere lo stato della sessione. Il cookie di sessione viene utilizzato per identificare la sessione dell'utente e autenticare l'utente per successive richieste di autenticazione. Questo cookie viene tipicamente impostato con i flag HttpOnly e Secure per prevenire accessi lato client e garantire una comunicazione sicura.

Una sessione per un singolo RP#

Per ogni RP a cui l'utente accede da dispositivi o browser diversi, verrà stabilita una sessione di accesso utente separata. Ciò significa che lo stato di autenticazione dell'utente è mantenuto separatamente per ciascun RP. Se l'utente effettua il logout da un RP, l'utente sarà ancora autenticato presso altri RP fino a quando la sessione non scade o l'utente effettua il logout da tutti gli RP.

Sessione centralizzata per più RP#

Questa gestione centralizzata delle sessioni consente anche all'IdP di mantenere uno stato di autenticazione coerente tra più RP fintanto che la sessione dell'utente è attiva e le richieste di autenticazione provengono dallo stesso agente utente (dispositivo/browser). Questo meccanismo abilita le funzionalità SSO, in cui l'utente può accedere a più RP senza dover effettuare un nuovo login.

Stato di autenticazione lato client#

In OIDC, l'applicazione client (RP) si affida ai token emessi dall'IdP per verificare l'identità e lo stato di autenticazione o autorizzazione dell'utente. La "sessione di accesso" sul lato client è mantenuta dai token emessi dall'IdP.

• ID Token: Un token di breve durata che contiene informazioni sull'utente ed è utilizzato per verificare l'identità dell'utente autenticato.
• Access Token: Un token che concede l'accesso a risorse protette per conto dell'utente. La durata del token di accesso può essere di breve durata o lunga durata, a seconda della configurazione. Le applicazioni client possono affidarsi alla validità del token di accesso per determinare lo stato di autenticazione dell'utente. Se il token di accesso è scaduto o cancellato, l'utente può essere considerato "disconnesso" o "non autenticato" e deve essere nuovamente autenticato.
• Refresh Token: Se l'ambito offline_access è richiesto e concesso, l'applicazione client può ricevere un token di aggiornamento. Fornisce un mezzo per estendere lo stato di autenticazione dell'utente senza richiedere all'utente di autenticarsi nuovamente. L'applicazione client può utilizzare il token di aggiornamento per ottenere un nuovo token di accesso quando il token di accesso corrente scade. Finché il token di aggiornamento è valido, lo stato di autenticazione dell'utente può essere mantenuto senza bisogno di interazione con l'utente.

La combinazione di questi token consente all'applicazione client di mantenere lo stato di autenticazione dell'utente e accedere alle risorse protette per conto dell'utente. L'applicazione client deve memorizzare in modo sicuro questi token e gestire il loro ciclo di vita. (Es. Per le applicazioni SPA, i token possono essere memorizzati nello storage locale o nello session storage del browser. Per le applicazioni web, i token possono essere memorizzati nei dati della sessione lato server o nei cookie.)

Meccanismi di disconnessione OIDC#

Il processo di disconnessione in OIDC è un concetto sfaccettato a causa del coinvolgimento di sessioni di accesso centralizzate gestite dall'IdP e token lato client distribuiti.

Cancellare token e sessione locale lato client#

Disconnettere o revocare lo stato di autenticazione di un utente sul lato client è relativamente semplice. L'applicazione client può rimuovere i token memorizzati (ID token, access token e refresh token) dal browser o dalla memoria dell'utente. Questa azione invalida efficacemente lo stato di autenticazione dell'utente sul lato client.

Per le applicazioni web che gestiscono le proprie sessioni di accesso degli utenti, possono essere necessari passaggi aggiuntivi. Questi includono la cancellazione del cookie di sessione e di eventuali dati di sessione (come i token emessi dal Fornitore di Identità, o IdP) per garantire che l'utente sia completamente disconnesso.

Cancellare la sessione di accesso centralizzata all'IdP#

L'IdP mantiene una sessione di accesso centralizzata per ciascun utente. Finché questa sessione è attiva, l'utente può essere ri-autenticato automaticamente anche se i token lato client sono stati cancellati, consentendo di rilasciare nuovi token all'applicazione client senza richiedere ulteriori interazioni con l'IdP.

Per disconnettere completamente un utente dall'IdP, l'applicazione client (RP) può avviare una richiesta di disconnessione all'IdP. L'applicazione (RP) dovrebbe reindirizzare l'utente all'endpoint di chiusura sessione dell'IdP per terminare la sessione di accesso e cancellare i cookie di sessione. Questo assicura una disconnessione completa tra tutte le applicazioni (RPs) che condividono la stessa sessione centralizzata. Una volta che la sessione di accesso è terminata, ogni volta che l'IdP riceve una richiesta di token da uno qualsiasi degli RPs collegati che condividono la stessa sessione, l'IdP inviterà l'utente a ri-autenticarsi.

OIDC back-channel logout#

In alcuni casi, quando un utente si disconnette da un'applicazione (RP), potrebbe anche voler essere disconnesso automaticamente da tutte le altre applicazioni (RPs) senza ulteriori interazioni da parte dell'utente. Questo può essere realizzato utilizzando il meccanismo di back-channel logout.

Quando l'IdP riceve una richiesta di disconnessione da un RP, non solo cancella la sessione di accesso ma invia anche una notifica di logout back-channel a tutti gli RPs che utilizzano la stessa sessione e hanno un endpoint di logout back-channel registrato.

Quando gli RPs ricevono la notifica di logout back-channel, possono eseguire le azioni necessarie per cancellare la sessione e i token dell'utente, garantendo che l'utente sia completamente disconnesso da tutte le applicazioni.