En OIDC back-channel logout avslutar en användares sessioner i en app. Den återkallar inte kundens tenant

En OIDC back-channel logout avslutar en användares sessioner i en app. Den återkallar inte kundens tenant

Frågan som en MSP får från kunden efter ett incidentsamtal lyder: ”vår IdP skickade en back-channel logout, så kundens hela tenant är avstängd, eller hur?” Det korta svaret är nej. Enligt OpenID Connect Back-Channel Logout 1.0 skickar identitetsleverantören en signerad Logout Token via POST till en relying party, och den token anger en enda slutanvändare (issuer plus subject) och/eller en enda session. Saknas sessions-ID avslutar relying party alla den användarens sessioner hos just den relying party, och inget mer. Det finns inget tenant-claim och ingen innebörd av ”återkalla alla”.

Den här FAQ:n besvarar sex frågor som MSP:er ställer när en utloggningssignal förväxlas med offboarding. Vad bevisar ett 200 OK från utloggningsendpointen, och vad bevisar det inte? Varför ligger machine-to-machine-integrationer helt utanför utloggningsflödet? Varför avslutas inte app-sessionerna automatiskt när IdP-sessionen avslutas, som NIST SP 800-63C-4 (26 augusti 2025) konstaterar? Var hör en återkallningssignal på tenant- eller policynivå hemma, med CAEP över Shared Signals Framework, och varför ersätter inte ens den en auktoriseringskontroll vid varje anrop? Och varför är utloggning inte avetablering?

Regeln i den här texten är enkel: offboarding av en tenant är en administrations- och auktoriseringsåtgärd, aldrig en bieffekt av en utloggning. Källorna är texter från OpenID, IETF, NIST och OWASP, kontrollerade den 5 oktober 2026. Här finns ingen tokenkonstruktion och inget påstående om att någon Altovar-produkt skickar eller tar emot dessa utloggnings- eller shared signals-händelser.

Återkallas kundens hela tenant när IdP:n skickar en back-channel logout? Med kundens ord: ”de loggade ut, så alla hos den kunden är borta.” Svaret är nej. En Back-Channel Logout-begäran är en POST från identitetsleverantören till relying party som innehåller en signerad Logout Token, så som avsnitt 2.4 i OIDC Back-Channel Logout 1.0 definierar den. Token identifierar en slutanvändare via issuer och subject och/eller en session via sessions-ID. Det är den räckvidd standarden ger signalen.

När sessions-ID saknas avslutar relying party alla den användarens sessioner hos den relying party. Längre än så går inte standarden. Det är fortfarande en användare och en app. Att avsluta varje webbläsarsession som Alice har i ärendeportalen avslutar varken Bobs sessioner i samma portal eller Alices sessioner i en annan portal som aldrig fick någon Logout Token.

Logout Token bär inget tenant-claim och betyder inte ”återkalla alla”. En relying party som behandlar en utloggning som återkallning av tenanten hittar på ett beteende som specifikationen inte definierar. Att återkalla en tenant, som en uppsättning separata administrativa åtgärder snarare än en produktgenomgång, innebär att inaktivera tenantposten, återkalla dess grants och klientregistreringar, rotera de autentiseringsuppgifter den innehar och se till att policybeslutspunkten nekar dess anrop. Varje åtgärd har en ägare och ett revisionsspår. Ingen av dem är en utloggning.

En kort kommentar om signaturer, på övergripande nivå: specifikationen kräver att Logout Token är signerad och kortlivad just för att en relying party inte ska agera på en förfalskad eller återspelad utloggning. Den här artikeln beskriver inte hur en token byggs eller kontrolleras. Det som räknas för MSP:n är räckvidden: en användare, en app, inte kundens tenant.

Utloggningsendpointen returnerade 200 OK. Är alla användarens tokens döda? Inte nödvändigtvis. Ett 200 OK betyder att relying party har rensat tillståndet för de sessioner den fick besked om. Det är ett kvitto från den relying party, inte ett bevis på att varje token överallt är borta.

Refresh tokens följer en snävare regel enligt avsnitt 2.7 i Back-Channel Logout. Refresh tokens som är knutna till den utloggade sessionen och utfärdade utan offline_access BÖR återkallas; refresh tokens med offline access BÖR normalt INTE återkallas. Det är en generell egenskap hos standarden. Den här artikeln kopplar den inte till någon leverantörs konfiguration och anger inga värden för inaktivitet eller livslängd.

Access tokens är en annan historia. En självständig (JWT-)access token förblir giltig tills den löper ut, såvida inte resursservern kontrollerar den i realtid via introspection (RFC 7662) eller token återkallas hos auktoriseringsservern (RFC 7009). Avsnitt 3 i RFC 7009 påpekar själv att omedelbar återkallning av självständiga access tokens kräver extra, icke-standardiserad samordning mellan auktoriseringsserver och resursserver, eller korta livslängder för tokens. Ett 200 OK vid utloggning är inte den samordningen.

Ett skyddsräcke för introspection, i en mening: active: true betyder att token har utfärdats och varken är återkallad eller utgången. Det säger ingenting om huruvida den här tenanten eller den här åtgärden är tillåten. Det är en separat fråga, som den här texten inte fördjupar. OWASP Session Management Cheat Sheet lägger till en rad: utloggning måste ogiltigförklara sessionen på serversidan; att radera en webbläsarcookie är inte samma sak.

Stänger utloggning av machine-to-machine-integrationer? Nej. Back-Channel Logout avslutar slutanvändares sessioner hos relying parties. En maskinklient som hämtar tokens via client credentials-grant har ingen användarsession och inget sessions-ID, så en Logout Token kan inte rikta sig mot den. Signalen har ingenstans att landa.

Konsekvensen för MSP:n, i klartext: RMM-kopplingen, faktureringssynken och backupagentens API-klient fortsätter att fungera efter att varje person hos kunden har loggats ut. Det är korrekt protokollbeteende, och det är precis därför ”vi loggade ut alla” inte är något offboardingunderlag. Människorna är borta från de appar som fick en Logout Token. Integrationerna är inte människor och fick ingen.

Offboarding av en integration är en egen checklista, formulerad som resultat snarare än klick i en produkt: inaktivera eller rotera klientens autentiseringsuppgifter, återkalla de tokens den redan har och ta bort dess behörighet till tenanten vid beslutspunkten. Var och en av dessa är en administrations- och auktoriseringsåtgärd med en ägare. Ingen av dem uppstår genom en utloggnings-POST.

Avslutas app-sessionerna automatiskt när IdP-sessionen avslutas? Nej. NIST SP 800-63C-4 (slutlig Revision 4, sida daterad 26 augusti 2025) säger att när abonnentens session hos IdP:n avslutas ”avslutas inte nödvändigtvis” de sessioner som abonnenten kan ha hos efterföljande RP:er (vår översättning). Parterna kan skicka sessionsslutshändelser till varandra om federationsprotokollet stöder det, eller via delade signaler. ”Kan” är inte ”kommer att”.

Back-Channel Logout är en sådan mekanism, och den fungerar enligt best effort. Relying party måste registrera en URI för back-channel logout, identitetsleverantören måste kunna nå den, och den försöker igen endast efter fel som den bedömer som återställbara (avsnitt 2.5 i Back-Channel Logout). En app som aldrig registrerade sig, eller som inte gick att nå när IdP:n skickade sin POST, behåller sin session. En brandväggsregel, en inaktuell URI eller en saknad registrering räcker för att en aktiv session ska bli kvar.

Avsnitt 5 i NIST SP 800-63B-4 tillför en begreppsförklaring: sessioner avslutas vid timeout eller explicit utloggning, och federationsbeteendet hänvisas till 63C. ”IdP-sessionen löpte ut” och ”varje app loggade ut” är alltså två olika fakta. Ett MSP-ärende som blandar ihop dem stänger fel arbete.

Att logga ut en användare tar inte heller bort medlemskapet i tenanten eller rollerna. NIST SP 800-63C-4 behandlar avslut av ett abonnentkonto hos relying party – borttagning av identifierare, autentiserare och attribut – som en separat åtgärd från att avsluta en session. Medlemskap och roller är provisionerings- och auktoriseringsdata; att ändra dem är avetablering. Raden att komma ihåg: sessionsslut ≠ kontoavslut ≠ offboarding av tenanten.

Var hör en återkallning på tenantnivå hemma, om inte i en Logout Token? OpenID Shared Signals Framework 1.0 med Continuous Access Evaluation Profile (CAEP 1.0, båda Final) definierar händelserna session-revoked och token-claims-change. Deras subjekt kan vara ett sammansatt subjekt som innehåller en tenantkomponent. Närmare än så kommer ingen standard ett återkallningsmeddelande på tenant- eller policynivå.

Det är fortfarande en signal: mottagaren avgör vad som ska göras med den. Att ta emot en händelse är inte detsamma som att ha återkallat åtkomsten. En produkt som ignorerar händelsen, fördröjer den eller gör om den till en mild varning har inte verkställt nekandet. Händelsen är en utlösare, inte beslutet.

Auktoriseringen i produkten måste fortfarande neka som standard och kontrollera tenantstatus och behörigheter vid varje anrop, så som OWASP Authorization Cheat Sheet beskriver det. En utloggning eller en CAEP-händelse utlöser den kontrollen, men ersätter den inte. En MSP som likställer ”CAEP mottagen” med ”åtkomst återkallad” hoppar över beslutspunkten.

Den här artikeln säger inte vilka produkter som skickar eller tar emot CAEP. Den säger i synnerhet inte att Auris gör det. Artikeln beskriver enbart standarden och påstår inte att någon Altovar-produkt stöder CAEP, SSF eller back-channel logout.

Det här är ingen FAQ om PAR, PKCE eller passkeys. De ämnena handlar om hur en inloggning eller en auktoriseringsbegäran börjar. Den här texten handlar om vad en utloggningssignal avslutar. Att starta en begäran och att avsluta en session är olika uppgifter, och den som blandar ihop dem skapar fel ärende.

Det är inte heller någon FAQ om group claims eller SCIM. Provisionerings- och rolldata nämns här bara för att konstatera att utloggning inte ändrar dem. Medlemskapsposter och rolltilldelningar överlever en Logout Token så länge ingen separat administrativ åtgärd tar bort dem.

Lika lite handlar det om DPoP eller om bindningsceremonier för autentiserare. Avsändarbindning (sender constraint) och autentiserarbindning besvarar andra frågor än utloggningens räckvidd.

Och det handlar inte om kortlivade tokens eller token-TTL. De ämnena handlar om hur länge en token lever. Här handlar det om utloggningssignalens räckvidd – session eller användare kontra tenant – inte om livslängd. En kortlivad access token och en Logout Token kan båda finnas i samma stack och ändå lämna maskinklienter och andra appar orörda.

Den här artikeln påstår inte att Auris stöder back-channel logout, CAEP eller SSF, annonserar backchannel_logout_supported, respekterar en backchannel_logout_uri per klient eller skickar shared signals-händelser.

Raden att upprepa: en utloggningssignal avslutar sessioner; att återkalla en kunds tenant är ett medvetet administrations- och auktoriseringsbeslut som kontrolleras vid varje anrop.