Een OIDC back-channel logout beëindigt de sessies van een gebruiker bij één app. Het trekt de tenant van de klant niet in

Een OIDC back-channel logout beëindigt de sessies van een gebruiker bij één app. Het trekt de tenant van de klant niet in

De vraag die een MSP na een incidentgesprek van de klant krijgt, luidt: “onze IdP heeft een back-channel logout gestuurd, dus de hele tenant van de klant is afgesloten, toch?” Het korte antwoord is nee. Volgens OpenID Connect Back-Channel Logout 1.0 stuurt de identity provider via een POST een ondertekend Logout Token naar een relying party, en dat token noemt één eindgebruiker (issuer plus subject) en/of één sessie. Zonder sessie-ID beëindigt de relying party alle sessies van die gebruiker bij die relying party, en verder niets. Er is geen tenant-claim en geen betekenis van “trek iedereen in”.

Deze FAQ beantwoordt zes vragen die MSP's stellen wanneer een logoutsignaal wordt verward met offboarding. Wat bewijst een 200 OK van het logout-endpoint, en wat bewijst het niet? Waarom vallen machine-to-machine-integraties volledig buiten het logoutpad? Waarom beëindigt het afsluiten van de IdP-sessie niet automatisch de app-sessies, zoals NIST SP 800-63C-4 (26 augustus 2025) stelt? Waar hoort een intrekkingssignaal op tenant- of beleidsniveau thuis, onder CAEP via het Shared Signals Framework, en waarom vervangt ook dat nog steeds niet de autorisatiecontrole bij elk verzoek? En waarom is logout geen deprovisioning?

De regel van dit stuk is eenvoudig: het offboarden van een tenant is een beheer- en autorisatiehandeling, nooit een neveneffect van een logout. De bronnen zijn de teksten van OpenID, IETF, NIST en OWASP, gecontroleerd op 5 oktober 2026. Er is geen tokenconstructie en geen bewering dat een product van Altovar deze logout- of shared-signals-events verstuurt of ontvangt.

Wordt de hele tenant van de klant ingetrokken wanneer de IdP een back-channel logout stuurt? In de woorden van de klant: “ze zijn uitgelogd, dus iedereen bij die klant is eruit.” Het antwoord is nee. Een Back-Channel Logout-verzoek is een POST van de identity provider naar de relying party met een ondertekend Logout Token, zoals gedefinieerd in sectie 2.4 van OIDC Back-Channel Logout 1.0. Het token identificeert één eindgebruiker via issuer en subject, en/of één sessie via de sessie-ID. Dat is de reikwijdte die de standaard aan het signaal geeft.

Als de sessie-ID ontbreekt, beëindigt de relying party alle sessies van die gebruiker bij die relying party. Verder gaat de standaard niet. Het blijft één gebruiker en één app. Wie elke browsersessie van Alice op het ticketportaal beëindigt, beëindigt daarmee niet de sessies van Bob op hetzelfde portaal, en ook niet die van Alice op een ander portaal dat nooit een Logout Token heeft ontvangen.

Het Logout Token bevat geen tenant-claim en betekent niet “trek iedereen in”. Een relying party die een logout behandelt als intrekking van de tenant, verzint gedrag dat de specificatie niet definieert. Het intrekken van een tenant, als reeks afzonderlijke beheerhandelingen en niet als productwalkthrough, betekent: het tenantrecord uitschakelen, de grants en clientregistraties intrekken, de credentials die de tenant bezit roteren en ervoor zorgen dat het policy decision point de verzoeken weigert. Elke handeling heeft een eigenaar en een audittrail. Geen daarvan is een logout.

Een korte opmerking over handtekeningen, op hoofdlijnen: de specificatie vereist dat het Logout Token ondertekend en kortlevend is, juist zodat een relying party niet handelt op een vervalste of opnieuw afgespeelde logout. Dit artikel beschrijft niet hoe een token wordt opgebouwd of gecontroleerd. Waar het voor de MSP om gaat, is de reikwijdte: één gebruiker, één app, niet de tenant van de klant.

Het logout-endpoint gaf 200 OK terug. Zijn alle tokens van de gebruiker dan ongeldig? Niet per se. Een 200 OK betekent dat de relying party de status heeft gewist van de sessies die haar zijn doorgegeven. Het is een ontvangstbewijs van die relying party, geen bewijs dat elk token overal verdwenen is.

Voor refresh tokens geldt volgens sectie 2.7 van Back-Channel Logout een engere regel. Refresh tokens die aan de uitgelogde sessie zijn gekoppeld en zonder offline_access zijn uitgegeven, horen in principe te worden ingetrokken (SHOULD); offline-access-refresh-tokens normaal gesproken niet (SHOULD NOT). Dat is een algemene eigenschap van de standaard. Dit artikel koppelt die niet aan de configuratie van een leverancier en noemt geen idle- of levensduurwaarden.

Access tokens vertellen een ander verhaal. Een zelfstandig (JWT-)access token blijft geldig tot het verloopt, tenzij de resource server het live controleert via introspection (RFC 7662) of het token wordt ingetrokken bij de authorization server (RFC 7009). Sectie 3 van RFC 7009 merkt zelf op dat het direct intrekken van zelfstandige access tokens extra, niet-gestandaardiseerde afstemming tussen authorization server en resource server vereist, of korte tokenlevensduren. Een 200 OK op de logout is niet die afstemming.

Eén vangrail voor introspection, in één zin: active: true betekent dat het token is uitgegeven en niet is ingetrokken of verlopen. Het zegt niets over de vraag of deze tenant of deze actie is toegestaan. Dat is een aparte vraag, waar dit stuk niet verder op ingaat. De OWASP Session Management Cheat Sheet voegt er één regel aan toe: een logout moet de sessie aan de serverkant ongeldig maken; een browsercookie verwijderen is niet hetzelfde.

Sluit een logout machine-to-machine-integraties af? Nee. Back-Channel Logout beëindigt sessies van eindgebruikers bij relying parties. Een machineclient die tokens verkrijgt via de client-credentials-grant heeft geen gebruikerssessie en geen sessie-ID, dus een Logout Token kan hem niet adresseren. Het signaal kan nergens landen.

Het gevolg voor de MSP, in gewone woorden: de RMM-connector, de facturatiesynchronisatie en de API-client van de back-upagent blijven werken nadat elke persoon bij de klant is uitgelogd. Dat is correct protocolgedrag, en precies daarom is “we hebben iedereen uitgelogd” geen offboardingverslag. De mensen zijn weg uit de apps die een Logout Token hebben ontvangen. De integraties zijn geen mensen en hebben er geen ontvangen.

Het offboarden van een integratie is een eigen checklist, geformuleerd als resultaten en niet als klikken in een product: de credentials van de client uitschakelen of roteren, de tokens die hij al heeft intrekken en zijn recht op de tenant verwijderen op het beslispunt. Elk daarvan is een beheer- en autorisatiehandeling met een eigenaar. Geen daarvan komt voort uit een logout-POST.

Beëindigt het afsluiten van de IdP-sessie automatisch de app-sessies? Nee. NIST SP 800-63C-4 (definitieve Revision 4, pagina gedateerd 26 augustus 2025) stelt dat het beëindigen van de sessie van de subscriber bij de IdP sessies die deze subscriber bij downstream-RP's heeft “niet noodzakelijkerwijs beëindigt” (onze vertaling). Beide partijen kunnen elkaar sessie-einde-events doorgeven als het federatieprotocol dat ondersteunt, of via shared signaling. “Kunnen” is niet “zullen”.

Back-Channel Logout is zo'n mechanisme, en het werkt op basis van best effort. De relying party moet een back-channel-logout-URI registreren, de identity provider moet die kunnen bereiken, en hij probeert het alleen opnieuw na fouten die hij herstelbaar acht (sectie 2.5 van Back-Channel Logout). Een app die zich nooit heeft geregistreerd, of onbereikbaar was toen de IdP de POST verstuurde, behoudt haar sessie. Een firewallregel, een verouderde URI of een ontbrekende registratie is genoeg om een actieve sessie achter te laten.

Sectie 5 van NIST SP 800-63B-4 voegt een begripsverheldering toe: sessies eindigen door een time-out of een expliciete logout, en federatiegedrag wordt naar 63C verwezen. “De IdP-sessie is verlopen” en “elke app heeft uitgelogd” zijn dus twee verschillende feiten. Een MSP-ticket dat ze door elkaar haalt, sluit het verkeerde werk af.

Een gebruiker uitloggen verwijdert ook niet zijn lidmaatschap van de tenant of zijn rollen. NIST SP 800-63C-4 behandelt het beëindigen van een subscriber-account bij de relying party (het verwijderen van identifiers, authenticators en attributen) als een handeling die los staat van het beëindigen van een sessie. Lidmaatschap en rollen zijn provisioning- en autorisatiegegevens; ze wijzigen is deprovisioning. De zin om te onthouden: einde sessie ≠ beëindiging account ≠ offboarding van de tenant.

Waar hoort een intrekking op tenantniveau thuis, zo niet in een Logout Token? Het OpenID Shared Signals Framework 1.0 met het Continuous Access Evaluation Profile (CAEP 1.0, beide Final) definieert de events session-revoked en token-claims-change. Hun subject kan een samengesteld subject zijn met een tenantcomponent. Dichter bij een intrekkingsbericht op tenant- of beleidsniveau komt een standaard niet.

Het blijft een signaal: de ontvanger beslist wat ermee gebeurt. Een event ontvangen is niet hetzelfde als toegang hebben ingetrokken. Een product dat het event negeert, uitstelt of omzet in een zachte waarschuwing, heeft de weigering niet uitgevoerd. Het event is een trigger, niet de beslissing.

De autorisatie in het product moet nog steeds standaard weigeren en bij elk verzoek de tenantstatus en de rechten controleren, zoals de OWASP Authorization Cheat Sheet het formuleert. Een logout- of CAEP-event is een trigger voor die controle, geen vervanging ervan. Een MSP die “CAEP ontvangen” gelijkstelt aan “toegang ingetrokken”, slaat het beslispunt over.

Dit artikel zegt niet welke producten CAEP versturen of ontvangen. In het bijzonder zegt het niet dat Auris dat doet. Het artikel beschrijft alleen de standaard en beweert niet dat een product van Altovar CAEP, SSF of back-channel logout ondersteunt.

Dit is geen FAQ over PAR, PKCE of passkeys. Die onderwerpen gaan over hoe een login of een autorisatieverzoek begint. Dit stuk gaat over wat een logoutsignaal beëindigt. Een verzoek starten en een sessie beëindigen zijn verschillende taken, en wie ze door elkaar haalt, maakt het verkeerde ticket aan.

Het is ook geen FAQ over group claims of SCIM. Provisioning- en rolgegevens komen hier alleen aan bod om te zeggen dat een logout ze niet verandert. Lidmaatschapsrecords en roltoewijzingen overleven een Logout Token, tenzij een afzonderlijke beheerhandeling ze verwijdert.

Evenmin gaat het over DPoP of over bindingsceremonies voor authenticators. Sender constraint en authenticatorbinding beantwoorden andere vragen dan de reikwijdte van een logout.

En het gaat niet over kortlevende tokens of token-TTL's. Die onderwerpen gaan over hoe lang een token leeft. Dit stuk gaat over de reikwijdte van het logoutsignaal (sessie of gebruiker tegenover tenant), niet over de levensduur. Een kortlevend access token en een Logout Token kunnen allebei in een stack aanwezig zijn en machineclients en andere apps toch ongemoeid laten.

Dit artikel beweert niet dat Auris back-channel logout, CAEP of SSF ondersteunt, backchannel_logout_supported adverteert, een backchannel_logout_uri per client honoreert of shared-signals-events verstuurt.

De zin om te herhalen: een logoutsignaal beëindigt sessies; het intrekken van de tenant van een klant is een bewuste beheer- en autorisatiebeslissing, die bij elk verzoek wordt gecontroleerd.