Wylogowanie przez back-channel w OIDC kończy sesje użytkownika w jednej aplikacji. Nie unieważnia ono dzierżawy klienta

Wylogowanie przez back-channel w OIDC kończy sesje użytkownika w jednej aplikacji. Nie unieważnia ono dzierżawy klienta

Pytanie, które MSP słyszy od klienta po rozmowie w sprawie incydentu, brzmi: „nasz IdP wysłał back-channel logout, więc cała dzierżawa (tenant) klienta jest odcięta, prawda?”. Krótka odpowiedź brzmi: nie. Zgodnie ze specyfikacją OpenID Connect Back-Channel Logout 1.0 dostawca tożsamości wysyła metodą POST podpisany Logout Token do strony ufającej (relying party), a ten token wskazuje jednego użytkownika końcowego (issuer plus subject) i/lub jedną sesję. Jeśli brakuje identyfikatora sesji, relying party kończy wszystkie sesje tego użytkownika w tej relying party – i nic więcej. Nie ma tu żadnego claimu dzierżawy ani znaczenia „unieważnij wszystkich”.

Ten FAQ odpowiada na sześć pytań, które MSP zadają, gdy sygnał wylogowania zostaje pomylony z offboardingiem. Co dowodzi odpowiedź 200 OK z endpointu wylogowania, a czego nie dowodzi? Dlaczego integracje machine-to-machine są całkowicie poza ścieżką wylogowania? Dlaczego zakończenie sesji w IdP nie kończy automatycznie sesji w aplikacjach, jak stwierdza NIST SP 800-63C-4 (26 sierpnia 2025 r.)? Gdzie mieści się sygnał unieważnienia o zakresie dzierżawy lub polityki – w CAEP na bazie Shared Signals Framework – i dlaczego nawet on nie zastępuje kontroli autoryzacji przy każdym żądaniu? I dlaczego wylogowanie nie jest deprovisioningiem?

Zasada tego tekstu jest prosta: offboarding dzierżawy to działanie administracyjne i autoryzacyjne, nigdy efekt uboczny wylogowania. Źródłami są teksty OpenID, IETF, NIST i OWASP zweryfikowane 5 października 2026 r. Nie ma tu konstruowania tokenów ani twierdzenia, że jakikolwiek produkt Altovar wysyła lub odbiera te zdarzenia wylogowania czy współdzielonych sygnałów.

Czy cała dzierżawa klienta zostaje unieważniona, gdy IdP wysyła back-channel logout? Słowami klienta: „wylogowali się, więc wszyscy u tego klienta są odcięci”. Odpowiedź brzmi: nie. Żądanie Back-Channel Logout to POST od dostawcy tożsamości do relying party zawierający podpisany Logout Token, zgodnie z definicją w sekcji 2.4 OIDC Back-Channel Logout 1.0. Token identyfikuje jednego użytkownika końcowego przez issuer i subject i/lub jedną sesję przez jej identyfikator. Taki zasięg standard nadaje temu sygnałowi.

Gdy brakuje identyfikatora sesji, relying party kończy wszystkie sesje tego użytkownika w tej relying party. Dalej standard nie sięga. Nadal chodzi o jednego użytkownika i jedną aplikację. Zakończenie każdej sesji przeglądarki Alicji w portalu zgłoszeń nie kończy sesji Boba w tym samym portalu ani sesji Alicji w innym portalu, który nigdy nie otrzymał Logout Tokenu.

Logout Token nie zawiera claimu dzierżawy i nie oznacza „unieważnij wszystkich”. Relying party, która traktuje wylogowanie jak unieważnienie dzierżawy, wymyśla zachowanie, którego specyfikacja nie definiuje. Unieważnienie dzierżawy – jako zestaw odrębnych czynności administracyjnych, a nie instrukcja obsługi produktu – oznacza wyłączenie rekordu dzierżawy, cofnięcie jej grantów i rejestracji klientów, rotację posiadanych przez nią poświadczeń oraz sprawienie, by punkt decyzyjny polityk (policy decision point) odrzucał jej żądania. Każda czynność ma właściciela i ślad audytowy. Żadna z nich nie jest wylogowaniem.

Krótka uwaga o podpisach, bez wchodzenia w szczegóły: specyfikacja wymaga, aby Logout Token był podpisany i krótkotrwały, właśnie po to, by relying party nie reagowała na sfałszowane lub odtworzone wylogowanie. Ten artykuł nie opisuje, jak token jest budowany ani weryfikowany. Dla MSP liczy się zasięg: jeden użytkownik, jedna aplikacja, a nie dzierżawa klienta.

Endpoint wylogowania zwrócił 200 OK. Czy wszystkie tokeny użytkownika są martwe? Niekoniecznie. 200 OK oznacza, że relying party wyczyściła stan sesji, o których ją poinformowano. To potwierdzenie od tej relying party, a nie dowód, że każdy token wszędzie przestał działać.

Refresh tokeny, zgodnie z sekcją 2.7 Back-Channel Logout, podlegają węższej regule. Refresh tokeny powiązane z zakończoną sesją i wydane bez offline_access POWINNY zostać unieważnione; refresh tokeny offline access zwykle NIE POWINNY. To ogólna właściwość standardu. Ten artykuł nie wiąże jej z konfiguracją żadnego dostawcy i nie podaje wartości bezczynności ani czasu życia.

Z access tokenami jest inaczej. Samodzielny (JWT) access token pozostaje ważny do wygaśnięcia, chyba że resource server sprawdza go na bieżąco przez introspekcję (RFC 7662) albo token zostanie unieważniony w authorization serverze (RFC 7009). Sama sekcja 3 RFC 7009 zauważa, że natychmiastowe unieważnienie samodzielnych access tokenów wymaga dodatkowej, niestandaryzowanej koordynacji między authorization serverem a resource serverem albo krótkiego czasu życia tokenów. Odpowiedź 200 OK na wylogowanie nie jest taką koordynacją.

Jedna zasada ostrożności dotycząca introspekcji, w jednym zdaniu: active: true oznacza, że token został wydany i nie jest unieważniony ani wygasły. Nie mówi nic o tym, czy ta dzierżawa lub ta operacja są dozwolone. To osobne zagadnienie, którego ten tekst nie rozwija. OWASP Session Management Cheat Sheet dodaje jeszcze jedno: wylogowanie musi unieważnić sesję po stronie serwera; usunięcie ciasteczka w przeglądarce to nie to samo.

Czy wylogowanie odcina integracje machine-to-machine? Nie. Back-Channel Logout kończy sesje użytkowników końcowych w relying parties. Klient maszynowy, który uzyskuje tokeny przez grant client credentials, nie ma sesji użytkownika ani identyfikatora sesji, więc Logout Token nie może go wskazać. Sygnał nie ma gdzie dotrzeć.

Konsekwencja dla MSP, mówiąc wprost: konektor RMM, synchronizacja rozliczeń i klient API agenta kopii zapasowych działają dalej, gdy każdy człowiek u klienta został już wylogowany. To poprawne zachowanie protokołu i właśnie dlatego „wylogowaliśmy wszystkich” nie jest protokołem offboardingu. Ludzie zniknęli z aplikacji, które otrzymały Logout Token. Integracje nie są ludźmi i żadnego nie otrzymały.

Offboarding integracji ma własną listę kontrolną, zapisaną jako rezultaty, a nie kliknięcia w produkcie: wyłączyć lub zrotować poświadczenia klienta, unieważnić tokeny, które już posiada, i odebrać mu uprawnienie do dzierżawy w punkcie decyzyjnym. Każdy z tych kroków to czynność administracyjna i autoryzacyjna z właścicielem. Żaden nie wynika z POST-a wylogowania.

Czy zakończenie sesji w IdP automatycznie kończy sesje w aplikacjach? Nie. NIST SP 800-63C-4 (ostateczna Revision 4, strona z datą 26 sierpnia 2025 r.) stwierdza, że zakończenie sesji subskrybenta w IdP „niekoniecznie zakończy” sesje, które ten subskrybent może mieć w kolejnych RP (tłumaczenie własne). Obie strony mogą przekazywać sobie zdarzenia zakończenia sesji, jeśli protokół federacji to obsługuje, albo przez współdzielone sygnały. „Mogą” to nie „będą”.

Back-Channel Logout jest jednym z takich mechanizmów i działa na zasadzie best effort. Relying party musi zarejestrować URI back-channel logout, dostawca tożsamości musi móc się z nim połączyć, a ponawia próbę tylko po błędach, które uznaje za możliwe do naprawienia (sekcja 2.5 Back-Channel Logout). Aplikacja, która nigdy się nie zarejestrowała lub była nieosiągalna, gdy IdP wysłał POST, zachowuje swoją sesję. Reguła firewalla, nieaktualny URI lub brak rejestracji wystarczą, by pozostała aktywna sesja.

Sekcja 5 NIST SP 800-63B-4 dodaje jedno zdanie definicji: sesje kończą się po przekroczeniu limitu czasu lub po jawnym wylogowaniu, a zachowanie w federacji odsyła się do 63C. „Sesja w IdP wygasła” i „każda aplikacja wylogowała użytkownika” to zatem dwa różne fakty. Zgłoszenie MSP, które je myli, zamknie niewłaściwą pracę.

Wylogowanie użytkownika nie usuwa też jego przynależności do dzierżawy ani ról. NIST SP 800-63C-4 traktuje zamknięcie konta subskrybenta w relying party – usunięcie identyfikatorów, authenticatorów i atrybutów – jako czynność odrębną od zakończenia sesji. Przynależność i role to dane provisioningu i autoryzacji; ich zmiana to deprovisioning. Zdanie do zapamiętania: koniec sesji ≠ zamknięcie konta ≠ offboarding dzierżawy.

Gdzie mieści się unieważnienie o zakresie dzierżawy, jeśli nie w Logout Tokenie? OpenID Shared Signals Framework 1.0 wraz z Continuous Access Evaluation Profile (CAEP 1.0, oba w wersji Final) definiuje zdarzenia session-revoked i token-claims-change. Ich podmiotem może być podmiot złożony, zawierający komponent dzierżawy. To najbliższy odpowiednik komunikatu o unieważnieniu w zakresie dzierżawy lub polityki, jaki oferuje standard.

To nadal jest sygnał: odbiorca decyduje, co z nim zrobić. Odebranie zdarzenia to nie to samo, co unieważnienie dostępu. Produkt, który ignoruje zdarzenie, opóźnia je lub zamienia w łagodne ostrzeżenie, nie wykonał odmowy. Zdarzenie jest wyzwalaczem, a nie decyzją.

Autoryzacja w produkcie nadal musi domyślnie odmawiać i przy każdym żądaniu sprawdzać status dzierżawy oraz uprawnienia, jak ujmuje to OWASP Authorization Cheat Sheet. Wylogowanie lub zdarzenie CAEP wyzwala tę kontrolę, ale jej nie zastępuje. MSP, który traktuje „odebrano CAEP” jak „dostęp unieważniony”, pomija punkt decyzyjny.

Ten artykuł nie mówi, które produkty wysyłają lub odbierają CAEP. W szczególności nie mówi, że robi to Auris. Artykuł opisuje wyłącznie standard i nie twierdzi, że jakikolwiek produkt Altovar obsługuje CAEP, SSF lub back-channel logout.

To nie jest FAQ o PAR, PKCE ani passkeyach. Te tematy dotyczą tego, jak zaczyna się logowanie lub żądanie autoryzacji. Ten tekst dotyczy tego, co kończy sygnał wylogowania. Rozpoczęcie żądania i zakończenie sesji to różne zadania, a mieszanie ich prowadzi do niewłaściwego zgłoszenia.

To również nie jest FAQ o group claims ani o SCIM. Dane provisioningu i ról pojawiają się tu tylko po to, by powiedzieć, że wylogowanie ich nie zmienia. Wpisy przynależności i przypisania ról przetrwają Logout Token, dopóki nie usunie ich odrębna czynność administracyjna.

Nie chodzi tu też o DPoP ani o ceremonie wiązania authenticatora. Ograniczenie do nadawcy (sender constraint) i wiązanie authenticatora odpowiadają na inne pytania niż zasięg wylogowania.

I nie chodzi o krótkotrwałe tokeny ani o TTL tokenów. Te tematy dotyczą tego, jak długo żyje token. Tu liczy się zasięg sygnału wylogowania – sesja lub użytkownik kontra dzierżawa – a nie czas życia. Krótkotrwały access token i Logout Token mogą współistnieć w jednym stosie i nadal nie dotknąć klientów maszynowych ani innych aplikacji.

Ten artykuł nie twierdzi, że Auris obsługuje back-channel logout, CAEP lub SSF, deklaruje backchannel_logout_supported, respektuje backchannel_logout_uri dla poszczególnych klientów ani wysyła zdarzenia współdzielonych sygnałów.

Zdanie do powtórzenia: sygnał wylogowania kończy sesje; unieważnienie dzierżawy klienta to świadoma decyzja administracyjna i autoryzacyjna, sprawdzana przy każdym żądaniu.