Jedno logowanie do wszystkiego: SSO na własnym serwerze

Problemem nie jest jedno złe hasło

Większość małych firm nie ma jednego problemu z logowaniem. Ma ich dwadzieścia.

Nowa osoba dostaje pocztę, miejsce na pliki, zdjęcia, sejf haseł, monitoring, VPN, może repozytorium kodu i kilka narzędzi dodanych później. Każda usługa chce własnego hasła. Część haseł ląduje w przeglądarce. Część ktoś wysyła na czacie. Część nadal działa po zmianie roli albo po odejściu z firmy.

To droga ataku. Raport Verizon Data Breach Investigations Report 2025 podaje, że czynnik ludzki wystąpił w około 60% naruszeń, a skradzione lub nadużyte dane logowania wciąż wracają jako jeden ze sposobów wejścia do firmowych systemów (Verizon DBIR). Praktyczny wniosek CISA wynika z tej samej lekcji: hasła powinny być długie, losowe, unikalne i trzymane w menedżerze haseł, bo jedno użyte ponownie hasło wystarczy, żeby zagrozić kilku kontom (CISA).

Rozproszone hasła to niezarządzany dostęp.

Co jedno logowanie zmienia na co dzień

Jedno logowanie nie oznacza, że „jedno słabe hasło otwiera wszystko”. Dobrze zrobione oznacza, że jeden system tożsamości decyduje, kim jesteś, jak mocno musisz to potwierdzić i do których aplikacji możesz wejść.

Tę rolę może pełnić dostawca tożsamości uruchomiony na własnym serwerze, taki jak Authentik albo Keycloak. Zasięg SSO zależy od integracji każdej aplikacji i jej obsługi współczesnych standardów logowania, takich jak OAuth2, OpenID Connect czy SAML — na przykład Nextclouda do plików, Immicha do zdjęć i Gitei do kodu, tam gdzie te integracje są włączone. Vaultwarden przyjmuje dostawcę OpenID Connect, gdy SSO zostanie dla niego włączone. Protokoły pocztowe, takie jak IMAP i SMTP, powstały przed logowaniem w stylu webowym, więc programy pocztowe na komputerze i telefonie zachowują własne hasła, nawet gdy interfejs webowy korzysta z centralnego logowania.

Dla zespołu widoczna zmiana jest celowo niepozorna:

jedno konto do założenia,
jedno miejsce do resetowania dostępu,
jedna zasada logowania dwuskładnikowego,
jedna lista grup, która decyduje, kto co widzi.

Sejf haseł nadal przechowuje sekrety do miejsc, które nie umieją korzystać z jednego logowania, a każda aplikacja zachowuje własne reguły wewnątrz. Ale pierwsza brama jest wspólna: mniej haseł, mniej zapomnianych kont, mniej miejsc do ręcznego sprzątania.

Mocniejsze logowanie bez dodatkowego rytuału

Druga korzyść: ostrzejsze zasady logowania stają się wykonalne. Żądanie, by każdy konfigurował logowanie dwuskładnikowe w pięciu miejscach, to prosty przepis na zignorowane zalecenia. Żądanie raz, w warstwie tożsamości, jest dużo łatwiejsze do przyjęcia.

Standardy pod spodem są ugruntowane. OAuth 2.0 opublikowano jako RFC 6749 w 2012 roku (RFC 6749); OpenID Connect 1.0 sfinalizowano w 2014 roku (OpenID Connect Core); jednorazowe kody czasowe opisuje RFC 6238 (RFC 6238); a klucze dostępu to dane logowania oparte na WebAuthn, zapisane na urządzeniu albo kluczu sprzętowym zamiast zapamiętywane jako tekst (W3C WebAuthn).

To, co faktycznie dzieje się po kliknięciu „zaloguj się”, to ustalona sekwencja — przepływ z kodem autoryzacyjnym (authorization code flow), zdefiniowana w RFC 6749 §4.1 i rozszerzona przez OIDC Core §3.1:

Przeglądarka jest przekierowywana do punktu autoryzacji dostawcy tożsamości, niosąc identyfikator klienta aplikacji, żądany zakres (żądania OIDC muszą zawierać wartość zakresu openid) oraz adres przekierowania.
Dostawca tożsamości uwierzytelnia Cię — hasło, drugi składnik, klucz dostępu, cokolwiek wymaga polityka — i w razie potrzeby prosi o zatwierdzenie dostępu.
Jeśli zatwierdzisz, dostawca tożsamości przekierowuje przeglądarkę z powrotem do aplikacji, dołączając krótkotrwały kod autoryzacyjny.
Serwer aplikacji wymienia ten kod na tokeny w punkcie tokenów dostawcy, uwierzytelniając się przy tym bezpośrednio wobec dostawcy (nie przez przeglądarkę).
Dostawca sprawdza kod i dane uwierzytelniające aplikacji, po czym zwraca token dostępu, a w przypadku OIDC także token ID identyfikujący Ciebie.
Aplikacja weryfikuje token ID i odczytuje z niego Twoją tożsamość, zamiast ufać nazwie użytkownika przekazanej wprost przez przeglądarkę.

Przeglądarka widzi tylko kroki 1–3; tokeny z kroków 4–5 przechodzą bezpośrednio między serwerem aplikacji a dostawcą tożsamości — RFC 6749 §1.3.1 opisuje to jako przekazanie tokenu „bez przechodzenia przez agenta użytkownika właściciela zasobu” (ang. without passing it through the resource owner’s user-agent).

Dostawcy tożsamości do samodzielnego uruchomienia realizują te same standardy: dokumentacja Authentika obejmuje na przykład dostawców OAuth2/OIDC i SAML oraz zarządzanie użytkownikami i grupami (dokumentacja Authentika). Aplikację, która mówi którymkolwiek z nich, zwykle da się do takiego dostawcy podpiąć.

Dla firmy liczy się kontrola: możesz wymagać mocniejszego potwierdzenia od grupy administratorów niż od konta tylko do odczytu i zmienić regułę raz, zamiast odwiedzać ustawienia każdej aplikacji z osobna.

Odbieranie dostępu powinno trwać minuty

Odejście pracownika jest trudniejsze od przyjęcia nowej osoby.

Gdy ktoś odchodzi, przełożony zwykle pamięta o poczcie i może o wspólnym dysku. A biblioteka zdjęć? Konto VPN założone pół roku temu? Testowe repozytorium? Stary dostęp administratora z migracji?

Przy jednym logowaniu lista jest krótsza: wyłączasz osobę u dostawcy tożsamości, usuwasz ją z grup, rotujesz sekrety, które mogła widzieć, i sprawdzasz ślad zdarzeń.

To nie kończy od razu każdej sesji i warto wiedzieć, dlaczego. Tokeny dostępu z założenia mają być ograniczone czasowo — RFC 6749 §5.1 zaleca, by odpowiedź podawała ich czas życia (expires_in; przykład podany wprost w RFC to 3600 sekund) — a każdy token ID w OIDC musi zawierać wymagane pole wygaśnięcia, exp (OIDC Core §2). Wyłączenie konta zatrzymuje wydawanie nowych tokenów i ich odnawianie przez dostawcę tożsamości, ale samo w sobie nie unieważnia tokenu, który aplikacja dostała wcześniej i który jeszcze nie wygasł. Część dostawców domyka to okno unieważnianiem tokenów albo wylogowaniem kanałem zwrotnym; czy dana aplikacja to obsługuje, warto sprawdzić, zanim na tym polegniesz. Krótkotrwały token sam się „zamyka” szybko; dłużej żyjący trzeba sprawdzić pod kątem wygaśnięcia. Niektóre narzędzia dodatkowo pamiętają dostęp poza czasem życia tokenu, część sekretów nadal trzeba wymienić, a wspólne skrzynki wymagają spisanej procedury. Różnica jest jednak duża: nie szukasz już po dziesięciu panelach administracyjnych, licząc, że wszystkie pamiętasz, i dokładnie wiesz, co znaczy „jeszcze nie do końca zamknięte”, zamiast zgadywać. Realistyczny cel to minuty na samo konto, plus tyle, ile wynosi czas życia najdłużej ważnego pozostałego tokenu.

Twój serwer, Twoja tożsamość

Jedno logowanie na własnym serwerze to mała zmiana o dużym skutku biznesowym. Dostęp staje się widoczny. Mocniejsze logowanie staje się praktyczne. Odejście z firmy jest kontrolowanym procesem, a nie testem pamięci.

Principale nie instaluje jeszcze dostawcy tożsamości — Authentik i Keycloak są w planach. Nextcloud już teraz można podłączyć do dostawcy OpenID Connect, którego uruchamiasz samodzielnie — przez aplikację OpenID Connect w Nextcloudzie, którą konfigurujesz sam — a zasięg jednego logowania zależy od integracji samej aplikacji.

principale.dev instaluje aplikacje, np. Nextcloud, na serwerze, który należy do Ciebie. Każda instalacja jest darmowa. Zobacz, jak to działa.