Gestione delle sessioni OIDC

Che cos'è la gestione delle sessioni OIDC#

OpenID Connect (OIDC) è un semplice livello di identità costruito sopra il protocollo OAuth 2.0. Permette ai client di verificare l'identità dell'utente finale basandosi sull'autenticazione eseguita dal server di autorizzazione, nonché di ottenere informazioni di base sul profilo dell'utente finale in una maniera 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à in applicazioni web, app mobili e API.

Comprendere lo stato di autenticazione e la gestione delle sessioni in OIDC è fondamentale. Questo articolo spiega come vengono gestite le sessioni OIDC e lo stato di autenticazione dell'utente nel contesto delle interazioni tra il Identity Provider (IdP) e il Relying Party (RP) o il Service Provider (SP).

Questo articolo include diversi termini chiave.

• Identity Provider (IdP): Il servizio che memorizza e autentica le identità degli utenti.
• Service Provider (SP) o Relaying Party (RP): Un'applicazione web o servizio che fornisce servizi agli utenti e si basa sull'IdP per l'autenticazione dell'utente.
• Sessione di accesso o Sessione di autenticazione: La sessione che viene stabilita quando un utente esegue l'accesso 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 dell'utente che permette a un utente di utilizzare un set di credenziali di accesso (ad 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, esaminiamo brevemente il flusso di autenticazione OIDC per un'applicazione web:

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

Che cos'è la gestione delle sessioni di accesso RP#

Una sessione di accesso viene stabilita quando un utente accede all'IdP. Questa sessione serve a monitorare lo stato di autenticazione dell'utente all'IdP. La sessione normalmente include informazioni come l'identità dell'utente, il tempo di autenticazione e il tempo di scadenza della sessione. Viene creata quando l'utente accede per la prima volta e viene mantenuta fino a quando l'utente esce o la sessione scade.

Un cookie di sessione verrà 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 autenticarlo per richieste di autenticazione successive. Questo cookie è tipicamente impostato con i flag HttpOnly e Secure per prevenire l'accesso lato client e garantire una comunicazione sicura.

Una sessione per un singolo RP#

Per ogni RP che l'utente accede da dispositivi o browser diversi, verrà stabilita una sessione separata di accesso utente. Ciò significa che lo stato di autenticazione dell'utente viene mantenuto separatamente per ciascun RP. Se l'utente esce da un RP, l'utente sarà ancora autenticato in altri RP fino a quando la sessione scade o l'utente esce da tutti i RP.

Sessione centralizzata per più RP#

Questa gestione centralizzata delle sessioni permette anche all'IdP di mantenere uno stato di autenticazione coerente attraverso 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 capacità SSO, dove l'utente può accedere a più RP senza dover accedere di nuovo.

Stato di autenticazione lato client#

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

• ID Token: Un token a breve durata che contiene le informazioni dell'utente ed è usato per verificare l'identità dell'utente autenticato.
• Access Token: Un token che garantisce l'accesso a risorse protette per conto dell'utente. La durata del token di accesso può essere breve o lunga, a seconda della configurazione. Le applicazioni client possono fare affidamento sulla 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 "uscito" o "non autenticato" e deve re-autenticarsi.
• Refresh Token: Se il campo offline_access viene richiesto e concesso, l'applicazione client può ricevere un refresh token. Fornisce un mezzo per estendere lo stato di autenticazione dell'utente senza richiedere che l'utente si ri-autentichi. L'applicazione client può usare il refresh token per ottenere un nuovo token di accesso quando il token di accesso corrente scade. Finché il refresh token è valido, lo stato di autenticazione dell'utente può essere mantenuto senza necessità di interazione dell'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 archiviare in modo sicuro questi token e gestirne il ciclo di vita. (Ad esempio, per le applicazioni SPA, i token possono essere memorizzati nello storage locale o nello storage della sessione del browser. Per le applicazioni web, i token possono essere memorizzati nei dati di sessione lato server o nei cookie.)

Meccanismi di uscita OIDC#

Il processo di uscita in OIDC è un concetto multifaccia a causa del coinvolgimento sia delle sessioni di accesso gestite centralmente da IdP che dei token distribuiti lato client.

Cancella token e sessione locale lato client#

Per uscire o revocare lo stato di autenticazione di un utente 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 lato client.

Per le applicazioni web che gestiscono le proprie sessioni di accesso utente, possono essere necessari passaggi aggiuntivi. Questi includono la cancellazione del cookie di sessione e di qualsiasi dato di sessione (come i token emessi dal Identity Provider, o IdP) per garantire che l'utente sia completamente uscito.

Cancella 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 automaticamente ri-autenticato anche se i token lato client sono stati cancellati, consentendo di emettere nuovi token all'applicazione client senza richiedere un'ulteriore interazione con l'IdP.

Per uscire completamente un utente dall'IdP, l'applicazione client (RP) può avviare una richiesta di uscita all'IdP. L'applicazione (RP) dovrebbe reindirizzare l'utente all'endpoint di fine sessione dell'IdP per terminare la sessione di accesso e cancellare i cookie di sessione. Questo garantisce un'uscita completa da tutte le applicazioni (RP) che condividono la stessa sessione centralizzata. Una volta terminata la sessione di accesso, ogni volta che l'IdP riceve una richiesta di token da qualsiasi RP collegato che condivide la stessa sessione, l'IdP chiederà all'utente di ri-autenticarsi.

Logout back-channel OIDC#

In alcuni casi, quando un utente esce da un'applicazione (RP), potrebbe voler essere automaticamente uscito da tutte le altre applicazioni (RP) senza ulteriori interazioni da parte dell'utente. Questo può essere ottenuto usando il meccanismo di logout back-channel.

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

Quando i RP 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 uscito da tutte le applicazioni.