Un back-channel logout OIDC chiude le sessioni di un utente su una sola app. Non revoca il tenant del cliente

Un back-channel logout OIDC chiude le sessioni di un utente su una sola app. Non revoca il tenant del cliente

La domanda che un MSP sente dopo una call d'incidente è: «l'IdP ha mandato un back-channel logout, quindi tutto il tenant del cliente è tagliato fuori, giusto?». La risposta breve è no. Con OpenID Connect Back-Channel Logout 1.0, l'identity provider invia a un relying party un Logout Token firmato, e quel token nomina un solo utente finale (issuer più subject) e/o una sola sessione. Se manca l'identificativo di sessione, il relying party chiude tutte le sessioni di quell'utente presso quel relying party, e basta. Non c'è un claim di tenant e non c'è un significato di «revoca tutti».

Questa FAQ risponde a sei domande che gli MSP pongono quando un segnale di logout viene scambiato per off-boarding. Cosa prova e cosa non prova un 200 OK dall'endpoint di logout? Perché le integrazioni machine-to-machine restano del tutto fuori dal percorso di logout? Perché chiudere la sessione sull'IdP non chiude da sola le sessioni sulle app, come dice NIST SP 800-63C-4 (26 agosto 2025)? Dove vive un segnale di revoca con ambito di tenant o di policy, sotto CAEP sullo Shared Signals Framework, e perché nemmeno quello sostituisce il controllo di autorizzazione a ogni richiesta? E perché il logout non è deprovisioning?

La regola del pezzo è semplice: l'off-boarding di un tenant è un'azione amministrativa e di autorizzazione, mai l'effetto collaterale di un logout. Le fonti sono i testi OpenID, IETF, NIST e OWASP verificati il 5 ottobre 2026. Non c'è alcuna costruzione di token né alcuna affermazione che un prodotto Altovar trasmetta o riceva questi eventi di logout o di segnalazione condivisa.

Il tenant del cliente è revocato quando l'IdP manda un back-channel logout? Con le parole del buyer: «hanno fatto logout, quindi tutti quelli di quel cliente sono fuori». La risposta è no. Una richiesta di Back-Channel Logout è una POST dall'identity provider al relying party con dentro un Logout Token firmato, come la definisce OIDC Back-Channel Logout 1.0 sezione 2.4. Il token identifica un utente finale con issuer e subject, e/o una sessione con il suo ID. Quello è il raggio che lo standard dà al segnale.

Quando manca l'ID di sessione, il relying party chiude tutte le sessioni di quell'utente presso quel relying party. È il massimo che lo standard prevede. Resta un solo utente e una sola app. Chiudere ogni sessione browser che Alice ha sul portale ticket non chiude le sessioni di Bob sullo stesso portale, e non chiude le sessioni di Alice su un altro portale che non ha mai ricevuto un Logout Token.

Il Logout Token non porta alcun claim di tenant e non significa «revoca tutti». Un relying party che tratta un logout come revoca del tenant inventa un comportamento che la specifica non definisce. La revoca di un tenant, come insieme di atti amministrativi separati e non come walkthrough di prodotto, significa disattivare il record del tenant, revocarne grant e registrazioni dei client, ruotare le credenziali che detiene, e far negare le sue richieste al policy decision point. Ogni atto ha un responsabile e una traccia di audit. Nessuno di questi è un logout.

Una breve nota sulle firme, senza scendere nei dettagli: la specifica chiede che il Logout Token sia firmato e di breve durata proprio perché il relying party non agisca su un logout falsificato o riprodotto. Questo articolo non descrive come si costruisce o si verifica il token. Il punto per l'MSP è il raggio: un utente, un'app, non il tenant del cliente.

L'endpoint di logout ha restituito 200 OK. Tutti i token dell'utente sono morti? Non necessariamente. Un 200 OK significa che il relying party ha ripulito lo stato delle sessioni che gli sono state indicate. È una ricevuta di quel relying party, non la prova che ogni token, ovunque, sia sparito.

I refresh token, da Back-Channel Logout sezione 2.7, seguono una regola più stretta. I refresh token legati alla sessione chiusa ed emessi senza offline_access DOVREBBERO essere revocati; quelli offline-access di norma NON DOVREBBERO esserlo. È una proprietà generica dello standard. Questo articolo non la lega alla configurazione di alcun fornitore e non cita valori di idle o di durata.

Gli access token raccontano un'altra storia. Un access token autocontenuto (JWT) resta valido fino alla scadenza, a meno che il resource server non lo verifichi in tempo reale con l'introspection (RFC 7662) o che il token venga revocato sull'authorization server (RFC 7009). La stessa RFC 7009 sezione 3 nota che la revoca immediata dei token autocontenuti richiede un coordinamento aggiuntivo e non standardizzato tra authorization server e resource server, oppure token di breve durata. Un 200 OK sul logout non è quel coordinamento.

Un paletto sull'introspection in una frase: active: true significa che il token è stato emesso e non è revocato né scaduto. Non dice nulla sul fatto che questo tenant o questa azione siano autorizzati. È una questione a parte, che questo pezzo non approfondisce. L'OWASP Session Management Cheat Sheet aggiunge un'altra riga: il logout deve invalidare la sessione lato server; cancellare il cookie nel browser non è la stessa cosa.

Il logout taglia fuori le integrazioni machine-to-machine? No. Il Back-Channel Logout chiude le sessioni degli utenti finali sui relying party. Un client macchina che ottiene token con il grant client-credentials non ha sessione utente né ID di sessione, quindi un Logout Token non può raggiungerlo. Il segnale non ha dove atterrare.

La conseguenza per l'MSP, in parole semplici: il connettore RMM, la sincronizzazione della fatturazione e il client API dell'agente di backup continuano a funzionare dopo che ogni persona del cliente è stata disconnessa. È il comportamento corretto del protocollo, ed è proprio il motivo per cui «abbiamo fatto logout a tutti» non è un verbale di off-boarding. Le persone sono fuori dalle app che hanno ricevuto un Logout Token. Le integrazioni non sono persone e non ne hanno ricevuto uno.

L'off-boarding di un'integrazione ha la sua checklist, scritta come risultati e non come clic di prodotto: disattivare o ruotare le credenziali del client, revocare i token che ha già, e togliere il suo diritto sul tenant al punto di decisione. Ciascuno di questi è un atto amministrativo e di autorizzazione con un responsabile. Nessuno nasce da una POST di logout.

Chiudere la sessione sull'IdP chiude automaticamente le sessioni sulle app? No. NIST SP 800-63C-4 (Revision 4 finale, pagina del 26 agosto 2025) dice che terminare la sessione del sottoscrittore sull'IdP «non terminerà necessariamente» le sessioni che quel sottoscrittore può avere sui relying party a valle (traduzione nostra). Le due parti possono scambiarsi eventi di fine sessione se il protocollo di federazione lo prevede, o tramite segnalazione condivisa. «Possono» non è «lo faranno».

Il Back-Channel Logout è uno di questi meccanismi ed è best-effort. Il relying party deve registrare un URI di back-channel logout, l'identity provider deve riuscire a raggiungerlo, e ritenta solo dopo errori che ritiene recuperabili (Back-Channel Logout sezione 2.5). Un'app che non si è registrata, o che non era raggiungibile quando l'IdP ha inviato la POST, mantiene la sua sessione. Una regola firewall, un URI obsoleto o una registrazione mancante bastano a lasciare una sessione viva.

NIST SP 800-63B-4 sezione 5 aggiunge una frase di dizionario: le sessioni finiscono per timeout o per logout esplicito, e il comportamento federato è rimandato alla 63C. Quindi «l'IdP è scaduto» e «tutte le app hanno fatto logout» sono due fatti diversi. Un ticket MSP che li confonde chiuderà il lavoro sbagliato.

Fare logout a un utente non toglie nemmeno l'appartenenza al tenant né i ruoli. NIST SP 800-63C-4 tratta la chiusura dell'account sul relying party—rimozione di identificativi, authenticator e attributi—come atto separato dalla fine della sessione. Appartenenza e ruoli sono dati di provisioning e di autorizzazione; cambiarli è deprovisioning. La frase da ripetere è: fine sessione ≠ chiusura dell'account ≠ off-boarding del tenant.

Dove vive una revoca con ambito di tenant, se non in un Logout Token? Lo Shared Signals Framework 1.0 di OpenID, con il Continuous Access Evaluation Profile (CAEP 1.0, entrambi Final), definisce gli eventi session-revoked e token-claims-change. Il loro soggetto può essere un soggetto composto che include una componente di tenant. È quanto di più vicino uno standard offra a un messaggio di revoca con ambito di tenant o di policy.

Resta un segnale: chi lo riceve decide cosa farne. Ricevere un evento non equivale ad aver revocato l'accesso. Un prodotto che ignora l'evento, lo ritarda o lo mappa su un avviso soft non ha eseguito il deny. L'evento è un trigger, non la decisione.

L'autorizzazione di prodotto deve comunque negare di default e controllare stato del tenant e permessi a ogni richiesta, come inquadra l'OWASP Authorization Cheat Sheet. Un logout o un evento CAEP fa scattare quel controllo, non lo sostituisce. Un MSP che tratta «CAEP ricevuto» come «accesso revocato» salta il punto di decisione.

Questo articolo non dice quali prodotti trasmettono o ricevono CAEP. In particolare, non dice che lo fa Auris. L'articolo descrive solo lo standard e non afferma che alcun prodotto Altovar supporti CAEP, SSF o il back-channel logout.

Questa non è una FAQ su PAR, PKCE o passkey. Quei temi riguardano come parte un login o una richiesta di autorizzazione. Questo pezzo riguarda cosa chiude un segnale di logout. Avviare una richiesta e chiudere una sessione sono lavori diversi, e mescolarli produce il ticket sbagliato.

Non è nemmeno una FAQ sui group claim o su SCIM. Provisioning e ruoli compaiono qui solo per dire che il logout non li tocca. Le righe di appartenenza e i grant di ruolo sopravvivono a un Logout Token finché un atto amministrativo separato non li rimuove.

Non parla neppure di DPoP o delle cerimonie di binding dell'authenticator. Vincolo al mittente e binding dell'authenticator rispondono a domande diverse dal raggio del logout.

E non riguarda i token di breve durata o il TTL dei token. Quei temi riguardano quanto vive un token. Qui conta il raggio del segnale di logout—sessione o utente contro tenant—non la durata. Un access token di breve durata e un Logout Token possono entrambi essere presenti in uno stack e lasciare comunque intatti i client macchina e le altre app.

Questo articolo non afferma che Auris supporti back-channel logout, CAEP o SSF, che pubblicizzi backchannel_logout_supported, che onori un backchannel_logout_uri per client, o che trasmetta eventi di segnalazione condivisa.

La frase da ripetere: un segnale di logout chiude sessioni; revocare il tenant di un cliente è una decisione amministrativa e di autorizzazione deliberata, verificata a ogni richiesta.