Un OIDC back-channel logout încheie sesiunile unui utilizator într-o singură aplicație. Nu revocă tenantul clientului

Un OIDC back-channel logout încheie sesiunile unui utilizator într-o singură aplicație. Nu revocă tenantul clientului

Întrebarea pe care un MSP o aude de la client după un apel de incident este: „IdP-ul nostru a trimis un back-channel logout, deci întregul tenant al clientului este tăiat, nu-i așa?” Răspunsul scurt este nu. Conform OpenID Connect Back-Channel Logout 1.0, furnizorul de identitate trimite prin POST un Logout Token semnat către o relying party, iar acel token numește un singur utilizator final (issuer plus subject) și/sau o singură sesiune. Fără identificator de sesiune, relying party încheie toate sesiunile acelui utilizator la acea relying party, și nimic mai mult. Nu există niciun claim de tenant și nicio semnificație de „revocă pe toată lumea”.

Acest FAQ răspunde la șase întrebări pe care le pun MSP-urile atunci când un semnal de logout este confundat cu offboardingul. Ce dovedește un 200 OK de la endpointul de logout și ce nu dovedește? De ce integrările machine-to-machine sunt complet în afara traseului de logout? De ce încheierea sesiunii la IdP nu încheie automat sesiunile din aplicații, așa cum arată NIST SP 800-63C-4 (26 august 2025)? Unde se află un semnal de revocare la nivel de tenant sau de politică, prin CAEP peste Shared Signals Framework, și de ce nici acesta nu înlocuiește verificarea autorizării la fiecare cerere? Și de ce logoutul nu este deprovizionare?

Regula acestui articol este simplă: offboardingul unui tenant este o acțiune de administrare și de autorizare, niciodată un efect secundar al unui logout. Sursele sunt textele OpenID, IETF, NIST și OWASP verificate pe 5 octombrie 2026. Nu există nicio construcție de token și nicio afirmație că vreun produs Altovar transmite sau primește aceste evenimente de logout sau de semnale partajate.

Este revocat întregul tenant al clientului când IdP-ul trimite un back-channel logout? În cuvintele clientului: „s-au delogat, deci toată lumea de la acel client a plecat”. Răspunsul este nu. O cerere Back-Channel Logout este un POST de la furnizorul de identitate către relying party care conține un Logout Token semnat, așa cum îl definește secțiunea 2.4 din OIDC Back-Channel Logout 1.0. Tokenul identifică un utilizator final prin issuer și subject și/sau o sesiune prin ID-ul de sesiune. Aceasta este raza pe care standardul o dă semnalului.

Când ID-ul de sesiune lipsește, relying party încheie toate sesiunile acelui utilizator la acea relying party. Mai departe de atât standardul nu merge. Rămâne un singur utilizator și o singură aplicație. Încheierea tuturor sesiunilor de browser pe care Alice le are în portalul de tichete nu încheie sesiunile lui Bob din același portal și nici sesiunile lui Alice dintr-un alt portal care nu a primit niciodată un Logout Token.

Logout Tokenul nu conține niciun claim de tenant și nu înseamnă „revocă pe toată lumea”. O relying party care tratează un logout drept revocare a tenantului inventează un comportament pe care specificația nu îl definește. Revocarea unui tenant, ca set de acte administrative separate și nu ca ghid de produs, înseamnă dezactivarea înregistrării tenantului, revocarea granturilor și a înregistrărilor sale de clienți, rotirea credențialelor pe care le deține și configurarea punctului de decizie a politicilor astfel încât să îi refuze cererile. Fiecare act are un responsabil și o pistă de audit. Niciunul nu este un logout.

O scurtă notă despre semnături, fără detalii tehnice: specificația cere ca Logout Tokenul să fie semnat și de scurtă durată tocmai pentru ca o relying party să nu acționeze pe baza unui logout falsificat sau retransmis. Acest articol nu descrie cum se construiește sau cum se verifică un token. Pentru MSP contează raza: un utilizator, o aplicație, nu tenantul clientului.

Endpointul de logout a returnat 200 OK. Sunt morți toți tokenii utilizatorului? Nu neapărat. Un 200 OK înseamnă că relying party a șters starea sesiunilor despre care a fost anunțată. Este o confirmare de primire din partea acelei relying party, nu o dovadă că fiecare token, oriunde, a dispărut.

Refresh tokenii urmează o regulă mai strictă, conform secțiunii 2.7 din Back-Channel Logout. Refresh tokenii legați de sesiunea încheiată și emiși fără offline_access AR TREBUI revocați; refresh tokenii de tip offline access în mod normal NU AR TREBUI. Aceasta este o proprietate generică a standardului. Acest articol nu o leagă de configurația vreunui furnizor și nu indică valori de inactivitate sau de durată de viață.

Access tokenii spun o altă poveste. Un access token autonom (JWT) rămâne valid până la expirare, cu excepția cazului în care resource serverul îl verifică în timp real prin introspecție (RFC 7662) sau tokenul este revocat la authorization server (RFC 7009). Chiar secțiunea 3 din RFC 7009 notează că revocarea imediată a access tokenilor autonomi necesită o coordonare suplimentară, nestandardizată, între authorization server și resource server, sau durate de viață scurte. Un 200 OK la logout nu este acea coordonare.

O regulă de siguranță despre introspecție, într-o singură frază: active: true înseamnă că tokenul a fost emis și nu este revocat sau expirat. Nu spune nimic despre dacă acest tenant sau această acțiune sunt permise. Este o întrebare separată, pe care acest articol nu o dezvoltă. OWASP Session Management Cheat Sheet adaugă încă un rând: logoutul trebuie să invalideze sesiunea pe server; ștergerea unui cookie din browser nu este același lucru.

Taie logoutul integrările machine-to-machine? Nu. Back-Channel Logout încheie sesiunile utilizatorilor finali la relying parties. Un client de tip mașină care obține tokeni prin grantul client credentials nu are sesiune de utilizator și nici ID de sesiune, așa că un Logout Token nu îl poate viza. Semnalul nu are unde să ajungă.

Consecința pentru MSP, spusă simplu: conectorul RMM, sincronizarea facturării și clientul API al agentului de backup continuă să funcționeze după ce fiecare persoană de la client a fost delogată. Este comportamentul corect al protocolului și exact de aceea „i-am delogat pe toți” nu este o dovadă de offboarding. Oamenii au ieșit din aplicațiile care au primit un Logout Token. Integrările nu sunt oameni și nu au primit niciunul.

Offboardingul unei integrări are propria listă de verificare, formulată ca rezultate, nu ca pași într-un produs: dezactivarea sau rotirea credențialelor clientului, revocarea tokenilor pe care îi deține deja și retragerea dreptului său asupra tenantului la punctul de decizie. Fiecare dintre acestea este un act de administrare și de autorizare cu un responsabil. Niciunul nu rezultă dintr-un POST de logout.

Încheierea sesiunii la IdP încheie automat sesiunile din aplicații? Nu. NIST SP 800-63C-4 (Revision 4 finală, pagină datată 26 august 2025) spune că încheierea sesiunii abonatului la IdP „nu va încheia neapărat” sesiunile pe care acel abonat le poate avea la RP-urile din aval (traducerea noastră). Cele două părți își pot transmite evenimente de încheiere a sesiunii dacă protocolul de federare permite acest lucru sau prin semnale partajate. „Pot” nu înseamnă „vor”.

Back-Channel Logout este un astfel de mecanism și funcționează pe principiul best effort. Relying party trebuie să înregistreze un URI de back-channel logout, furnizorul de identitate trebuie să îl poată accesa și reîncearcă doar după erori pe care le consideră recuperabile (secțiunea 2.5 din Back-Channel Logout). O aplicație care nu s-a înregistrat niciodată sau care nu era accesibilă când IdP-ul a trimis POST-ul își păstrează sesiunea. O regulă de firewall, un URI învechit sau o înregistrare lipsă sunt suficiente pentru a lăsa în urmă o sesiune activă.

Secțiunea 5 din NIST SP 800-63B-4 adaugă o precizare de terminologie: sesiunile se încheie prin timeout sau prin logout explicit, iar comportamentul în federare este trimis la 63C. Așadar, „sesiunea la IdP a expirat” și „toate aplicațiile au făcut logout” sunt două fapte diferite. Un tichet MSP care le confundă va închide munca greșită.

Delogarea unui utilizator nu elimină nici apartenența la tenant, nici rolurile. NIST SP 800-63C-4 tratează închiderea unui cont de abonat la relying party (eliminarea identificatorilor, a autentificatorilor și a atributelor) ca act separat de încheierea sesiunii. Apartenența și rolurile sunt date de provizionare și de autorizare; modificarea lor înseamnă deprovizionare. Fraza de reținut: sfârșitul sesiunii ≠ închiderea contului ≠ offboardingul tenantului.

Unde se află o revocare la nivel de tenant, dacă nu într-un Logout Token? OpenID Shared Signals Framework 1.0, împreună cu Continuous Access Evaluation Profile (CAEP 1.0, ambele în versiune Final), definește evenimentele session-revoked și token-claims-change. Subiectul lor poate fi un subiect complex care include o componentă de tenant. Este cel mai aproape la care ajunge un standard de un mesaj de revocare la nivel de tenant sau de politică.

Rămâne un semnal: destinatarul decide ce face cu el. A primi un eveniment nu este același lucru cu a fi revocat accesul. Un produs care ignoră evenimentul, îl amână sau îl transformă într-un simplu avertisment nu a aplicat refuzul. Evenimentul este un declanșator, nu decizia.

Autorizarea din produs trebuie în continuare să refuze implicit și să verifice starea tenantului și permisiunile la fiecare cerere, așa cum o formulează OWASP Authorization Cheat Sheet. Un logout sau un eveniment CAEP declanșează acea verificare, nu o înlocuiește. Un MSP care tratează „CAEP primit” drept „acces revocat” sare peste punctul de decizie.

Acest articol nu spune ce produse transmit sau primesc CAEP. În special, nu spune că Auris face acest lucru. Articolul descrie doar standardul și nu afirmă că vreun produs Altovar acceptă CAEP, SSF sau back-channel logout.

Acesta nu este un FAQ despre PAR, PKCE sau passkeys. Acele subiecte privesc modul în care începe o autentificare sau o cerere de autorizare. Acest articol se referă la ce încheie un semnal de logout. A porni o cerere și a încheia o sesiune sunt sarcini diferite, iar amestecarea lor produce tichetul greșit.

Nu este nici un FAQ despre group claims sau SCIM. Datele de provizionare și de roluri apar aici doar pentru a spune că logoutul nu le modifică. Înregistrările de apartenență și atribuirile de roluri supraviețuiesc unui Logout Token, cu excepția cazului în care un act administrativ separat le elimină.

Nu este vorba nici despre DPoP sau despre ceremoniile de legare a autentificatorului. Constrângerea la expeditor (sender constraint) și legarea autentificatorului răspund la alte întrebări decât raza logoutului.

Și nu este vorba despre tokeni de scurtă durată sau despre TTL-ul tokenilor. Acele subiecte privesc cât trăiește un token. Aici contează raza semnalului de logout (sesiune sau utilizator față de tenant), nu durata de viață. Un access token de scurtă durată și un Logout Token pot exista amândouă într-un stack și pot lăsa totuși neatinși clienții de tip mașină și celelalte aplicații.

Acest articol nu afirmă că Auris acceptă back-channel logout, CAEP sau SSF, că declară backchannel_logout_supported, că respectă un backchannel_logout_uri per client sau că transmite evenimente de semnale partajate.

Fraza de repetat: un semnal de logout încheie sesiuni; revocarea tenantului unui client este o decizie deliberată de administrare și de autorizare, verificată la fiecare cerere.