Czym jest Keycloak? Otwarty serwer tożsamości i SSO

Czym jest Keycloak?

Keycloak to otwartoźródłowy serwer klasy Identity and Access Management (IAM) — oprogramowanie, które przejmuje na siebie logowanie użytkowników, zarządzanie sesjami oraz nadawanie uprawnień, zdejmując ten obowiązek z aplikacji biznesowych. Zamiast budować formularz logowania i mechanizm walidacji haseł osobno w każdej aplikacji, zespół deweloperski deleguje te procesy do jednego, centralnego serwera.

Trzeba od razu zaznaczyć, czym Keycloak nie jest. To nie jest model AI ani usługa SaaS w chmurze dostawcy. To samodzielne oprogramowanie infrastrukturalne — serwer, który uruchamiasz na własnych maszynach lub w klastrze Kubernetes i sam nim zarządzasz. W tym sensie jest bliższym krewnym bazy danych czy serwera aplikacji niż gotowej aplikacji końcowej.

Mechanika jest prosta w opisie. Keycloak uwierzytelnia użytkownika, a następnie wystawia aplikacji kryptograficznie podpisany token — najczęściej w formacie JSON Web Token^?JSON Web Token: podpisany token w formacie JSON, przenoszący dane o tożsamości i uprawnieniach (JWT) — zawierający informacje o tożsamości i przyznanych uprawnieniach. Aplikacja nie widzi hasła i nie przechowuje danych logowania. Otrzymuje tylko zweryfikowany token, któremu może zaufać.

Najważniejszą wartością, jaką wnosi, jest Single Sign-On^?Single Sign-On: jednokrotne logowanie — jedna sesja daje dostęp do wielu aplikacji (SSO). Użytkownik loguje się raz, a otwarta sesja automatycznie obejmuje wszystkie aplikacje podłączone do tego samego serwera Keycloak. Wylogowanie również działa globalnie. Dla organizacji z kilkunastoma wewnętrznymi systemami eliminuje to „zmęczenie hasłami" i centralizuje kontrolę nad bezpieczeństwem.

Kto za tym stoi?

Projekt został zainicjowany w 2013 roku przez Billa Burke'a i Stiana Thorgersena — deweloperów z grupy JBoss należącej do firmy Red Hat. Celem było stworzenie rozwiązania SSO opartego na otwartych standardach, dedykowanego początkowo aplikacjom w ekosystemie Javy. Pierwsza stabilna wersja produkcyjna ukazała się we wrześniu 2014 roku.

W 2016 roku Red Hat uczynił Keycloak projektem upstream dla swojego komercyjnego produktu Red Hat Single Sign-On (RH-SSO). Oznaczało to klarowny układ. Nowe funkcje powstawały i były testowane w otwartej społeczności Keycloak, a Red Hat pakował je, stabilizował i sprzedawał z komercyjnym wsparciem klientom korporacyjnym.

Kluczowy moment w historii projektu nastąpił w kwietniu 2023 roku, kiedy Keycloak został oficjalnie przyjęty przez Cloud Native Computing Foundation (CNCF) jako projekt na poziomie inkubacji^?poziomie inkubacji: środkowy z trzech etapów dojrzałości projektu w CNCF (Sandbox, Incubating, Graduated). Oznacza, że projekt jest już używany produkcyjnie przez wiele organizacji i ma stabilny, aktywny rozwój, ale nie osiągnął jeszcze najwyższego statusu Graduated zarezerwowanego dla w pełni dojrzałych technologii, jak Kubernetes. Był to strategiczny krok mający uniezależnić postrzeganie projektu od marki Red Hata i osadzić go głębiej w ekosystemie cloud-native, obok Kubernetes czy OpenTelemetry. Według stanu na 2025 i 2026 rok Keycloak pozostaje inkubowanym projektem CNCF z bardzo dużą społecznością — rzędu 34 tysięcy gwiazdek na GitHubie.

Jak to działa?

Sercem działania Keycloaka są otwarte protokoły uwierzytelniania i autoryzacji. Projekt świadomie nie narzuca własnych, zamkniętych formatów — jeśli aplikacja rozumie standardy branżowe, integracja powiedzie się niezależnie od języka programowania.

OAuth 2.0 i OpenID Connect

Podstawą jest para OAuth 2.0 i OpenID Connect (OIDC). OAuth 2.0 to framework autoryzacji — pozwala aplikacji uzyskać ograniczony dostęp do API w imieniu użytkownika za pomocą tokenu dostępu. Sam OAuth 2.0 nie zajmuje się jednak potwierdzaniem tożsamości. Dlatego Keycloak nakłada na niego warstwę OpenID Connect, która weryfikuje, kim jest użytkownik, i wystawia dodatkowy dowód tożsamości w postaci tokenu ID. Tokeny te są podpisane kryptograficznie i przenoszą tak zwane claims^?claims: poświadczenia o użytkowniku zawarte w tokenie, np. identyfikator, e-mail czy role, czyli poświadczenia o użytkowniku.

Authorization Code Flow

W typowym scenariuszu webowym stosuje się Authorization Code Flow. Aplikacja przekierowuje użytkownika do Keycloaka, ten przeprowadza logowanie, po czym odsyła użytkownika z powrotem wraz z kodem, który aplikacja wymienia na tokeny. Dla aplikacji przeglądarkowych i mobilnych dochodzi dodatkowe zabezpieczenie PKCE (Proof Key for Code Exchange), chroniące przed przechwyceniem kodu.

SAML 2.0

Drugim filarem jest SAML 2.0 — starszy standard oparty na wymianie podpisanych dokumentów XML zwanych asercjami. SAML uchodzi za cięższy w integracji, ale jest krytycznie ważny dla dużych systemów korporacyjnych i starszego oprogramowania, które nie obsługuje OIDC. Dzięki temu, że Keycloak obsługuje oba protokoły jednocześnie i dla tej samej bazy użytkowników, organizacja może równolegle utrzymywać nowoczesne mikrousługi i wiekowe systemy, prowadząc ich stopniową migrację.

Z jakich elementów się składa?

Model danych Keycloaka opiera się na kilku fundamentalnych pojęciach.

Realm

Realm (obszar) to najwyższy poziom izolacji. Każdy realm jest w pełni odseparowanym kontenerem z własnymi użytkownikami, rolami, aplikacjami i politykami bezpieczeństwa. Zmiana w jednym realmie nie wpływa na inne, co pozwala obsługiwać wielu klientów w modelu multi-tenant. Istnieje wydzielony Master Realm przeznaczony wyłącznie do administracji — dobrą praktyką jest nieumieszczanie w nim zwykłych aplikacji.

Klienci

Klienci (clients) to aplikacje chronione przez Keycloak. Dzielą się na publicznych (aplikacje SPA w przeglądarce i mobilne, które nie potrafią bezpiecznie przechować sekretu), poufnych (aplikacje serwerowe przechowujące client secret) oraz bearer-only (API weryfikujące jedynie przekazany token).

Role i grupy

Role i grupy realizują model kontroli dostępu opartej na rolach (RBAC). Role mogą być definiowane globalnie dla realmu albo lokalnie dla konkretnej aplikacji, a role złożone potrafią dziedziczyć inne. Grupy odwzorowują strukturę organizacyjną i upraszczają masowe przypisywanie uprawnień.

User Federation

User Federation to jeden z najmocniejszych elementów. Keycloak ma gotowe konektory do LDAP i Microsoft Active Directory, dzięki czemu potrafi synchronizować i wykorzystywać istniejące bazy użytkowników bez kosztownej migracji haseł.

Identity Brokering

Pokrewną funkcją jest Identity Brokering — Keycloak może delegować logowanie do zewnętrznych dostawców tożsamości, takich jak Google, GitHub czy firmowy serwer Okta, a aplikacja końcowa nie musi nawet wiedzieć, jakiej metody użył użytkownik.

Do czego może być używane?

Najczęstszym zastosowaniem jest centralne SSO dla zestawu aplikacji w jednej organizacji — pracownik loguje się raz i uzyskuje dostęp do wszystkich wewnętrznych narzędzi. Drugim popularnym scenariuszem jest zabezpieczanie architektur mikrousługowych, gdzie dziesiątki niezależnych usług muszą weryfikować tożsamość bez dublowania logiki logowania.

Keycloak sprawdza się też jako broker tożsamości w aplikacjach konsumenckich (B2C), gdzie udostępnia logowanie społecznościowe przez konta Google, Facebook czy GitHub. W scenariuszach bardziej zaawansowanych jego silnik Authorization Services pozwala budować szczegółowe reguły dostępu wykraczające poza proste role — na podstawie atrybutów użytkownika (ABAC^?ABAC: Attribute-Based Access Control — kontrola dostępu oparta na atrybutach użytkownika i kontekstu, np. dziale czy porze dnia, a nie tylko na przypisanych rolach), kontekstu czy standardu UMA 2.0^?UMA 2.0: User-Managed Access — rozszerzenie OAuth 2.0, w którym to właściciel zasobu (użytkownik) sam decyduje, komu i na jakich warunkach udostępnia swoje zasoby.

Wbudowany silnik przepływów logowania umożliwia wymuszanie uwierzytelniania wieloskładnikowego (MFA/2FA) za pomocą haseł jednorazowych TOTP^?TOTP: Time-based One-Time Password — jednorazowy kod wyliczany ze współdzielonego sekretu i bieżącego czasu, ważny zwykle 30 sekund (np. Google Authenticator, FreeOTP) albo logowania bezhasłowego opartego na standardzie WebAuthn^?WebAuthn: Web Authentication — standard W3C umożliwiający logowanie bez hasła za pomocą kluczy kryptograficznych przechowywanych na urządzeniu lub kluczu sprzętowym i kluczach FIDO2^?FIDO2: standard uwierzytelniania bez hasła (FIDO Alliance + WebAuthn) wykorzystujący klucze sprzętowe lub biometrię; klucz prywatny nigdy nie opuszcza urządzenia. Platforma dostarcza również konsolę Account Management, w której użytkownik samodzielnie zarządza profilem, oraz system motywów (themes) pozwalający dostosować wygląd stron logowania w podejściu white-label.

Authorization Services — autoryzacja drobnoziarnista

W większości aplikacji rola zaszyta w tokenie (RBAC^?RBAC: Role-Based Access Control — kontrola dostępu oparta na rolach przypisanych użytkownikowi. Jeśli masz rolę, masz przypisany do niej dostęp) wystarcza, by wpuścić albo odrzucić użytkownika. Role mają jednak ograniczenia: są sztywno powiązane z zasobami, nie niosą kontekstu, a samo posiadanie roli daje „jakiś" dostęp. Authorization Services to wbudowany w Keycloak silnik autoryzacji drobnoziarnistej^?autoryzacji drobnoziarnistej: fine-grained authorization — autoryzacja rozstrzygana na poziomie pojedynczych zasobów i akcji w oparciu o wiele warunków (role, atrybuty, kontekst), a nie tylko o grube role, zbudowany na OAuth 2.0 i UMA 2.0. Pozwala łączyć RBAC z kontrolą opartą na atrybutach (ABAC^?ABAC: Attribute-Based Access Control — kontrola dostępu oparta na atrybutach użytkownika i kontekstu, np. dziale czy porze dnia, a nie tylko na przypisanych rolach), kontekście, czasie i regułach, a decyzje przenosi z kodu aplikacji do centralnego punktu.

Cztery punkty autoryzacji

Keycloak rozdziela autoryzację na cztery role znane z klasycznego modelu polityk:

• PAP (Policy Administration Point) — konsola administracyjna i Protection API, gdzie definiuje się zasoby i polityki.
• PDP (Policy Decision Point) — centralny punkt, w którym zapada werdykt.
• PEP (Policy Enforcement Point) — egzekutor po stronie aplikacji, który pyta o decyzję i ją wymusza.
• PIP (Policy Information Point) — dostarcza atrybuty tożsamości i środowiska.

Aplikacja pyta — Keycloak decyduje.

Model: zasób, scope, polityka, uprawnienie

Punktem wyjścia jest resource server — poufny klient z włączoną autoryzacją. Na nim opierają się cztery fundamentalne pojęcia:

• Resource (zasób) — chroniony obiekt: endpoint, plik, „konto Alicji" jako pojedyncza instancja albo cały typ „konto bankowe".
• Scope — czasownik, czyli akcja na zasobie, na przykład view, edit czy delete.
• Policy (polityka) — opisuje sam warunek, jest wielokrotnego użytku i nie wskazuje chronionego obiektu.
• Permission (uprawnienie) — spina to razem według wzorca „X może zrobić Y na zasobie Z", łącząc zasób lub scope z politykami.

Rodzaje polityk

Keycloak dostarcza gotowe typy polityk pokrywające najczęstsze mechanizmy, a brakujące można dopisać przez SPI.

Każdą politykę można odwrócić logiką pozytywną lub negatywną, a złożone reguły budować przez agregację zamiast jednej wielkiej polityki.

Jak zapada decyzja: RPT i strategie

Sposób egzekwowania ustawia tryb polityki:

• Enforcing (domyślny) — brak polityki dla zasobu oznacza odmowę.
• Permissive — przy braku polityki dostęp jest przyznawany.
• Disabled — ocena polityk jest wyłączona.

Gdy kilka uprawnień dotyczy tego samego zasobu, wynik rozstrzyga strategia decyzji:

• Affirmative — wystarczy jedna pozytywna ocena.
• Unanimous — wszystkie muszą być pozytywne, jedno „nie" blokuje dostęp.

Efektem oceny jest RPT^?RPT: Requesting Party Token — access token niosący listę przyznanych uprawnień, wydawany przez Keycloak po ocenie polityk (RPT) — token z przyznanymi uprawnieniami, wydawany przez rozszerzenie endpointu tokenowego (grant UMA uma-ticket). Aplikacja może go zweryfikować lokalnie albo przez introspekcję.

UMA 2.0 i Protection API

Na wierzchu działa Protection API — zgodny z UMA zestaw endpointów (wymaga zakresu uma_protection), którym resource server zdalnie rejestruje zasoby i wystawia permission ticket^?permission ticket: nieprzejrzysty token UMA reprezentujący żądane zasoby i zakresy, wymieniany następnie na RPT (permission tickets). W przepływie UMA klient trafia na chroniony zasób, dostaje permission ticket, odsyła go do serwera autoryzacji i otrzymuje RPT. To otwiera scenariusze dzielenia zasobów między ludźmi (person-to-person), w których o dostępie decyduje sam właściciel zasobu.

Czym różni się od innych rozwiązań?

Główna oś podziału przebiega między modelem self-hosted a SaaS^?self-hosted a SaaS: self-hosted oznacza, że sam uruchamiasz i utrzymujesz oprogramowanie na własnej infrastrukturze; SaaS (Software as a Service) to gotowa usługa w chmurze dostawcy, rozliczana abonamentowo, bez serwerów do utrzymania. Auth0 i Okta to komercyjne usługi w chmurze — nie wymagają utrzymywania infrastruktury, ale rozliczają się za aktywnych użytkowników miesięcznie (per-MAU^?per-MAU: rozliczenie za miesięcznych aktywnych użytkowników (Monthly Active Users) — koszt rośnie wraz z liczbą logujących się osób), przez co koszty rosną nieliniowo wraz ze skalą. Keycloak jest darmowy w licencji (Apache 2.0) i daje pełną kontrolę nad danymi, ale przerzuca na zespół koszt utrzymania, patchowania i strojenia środowiska.

Wśród nowszych konkurentów open-source warto wymienić Authentik (napisany w Pythonie i Go, ceniony za prostotę i niskie zużycie pamięci), Zitadel (lekki, napisany w Go, z natywnym multi-tenancy^?multi-tenancy: obsługa wielu odrębnych klientów (najemców) w jednej instancji oprogramowania, z pełną izolacją ich danych i konfiguracji i API gRPC^?API gRPC: gRPC to wydajny, binarny protokół zdalnych wywołań (RPC) od Google, oparty na HTTP/2 i Protocol Buffers — szybszy i zwięźlejszy niż klasyczne REST/JSON, mocny w B2B SaaS) oraz Ory (Hydra i Kratos — podejście headless^?podejście headless: architektura bez wbudowanego interfejsu użytkownika — system udostępnia wyłącznie API, a warstwę UI, np. ekrany logowania, buduje się samodzielnie, rozbite na wyspecjalizowane mikrousługi). Na ich tle Keycloak wyróżnia się dojrzałością, najsilniejszym i w pełni certyfikowanym wsparciem SAML oraz potężną federacją z LDAP i Active Directory. To czyni go domyślnym wyborem dla dużych wdrożeń korporacyjnych, choć kosztem większej wagi i złożoności operacyjnej.

Keycloak w erze AI

Rozwój agentów AI i asystentów opartych na dużych modelach językowych postawił przed systemami tożsamości nowe pytanie — jak nadać tożsamość i kontrolować uprawnienia bytom, które nie są ludźmi. Keycloak, jako dojrzały serwer OAuth 2.0 i OIDC, odpowiada na te potrzeby kilkoma mechanizmami, które istniały już wcześniej, a teraz zyskują nowe zastosowanie.

Tożsamość maszyn i agentów

Podstawą jest mechanizm kont serwisowych (service accounts) oparty na przepływie client credentials. Agent lub usługa AI uwierzytelnia się własnymi poświadczeniami — bez udziału człowieka — i otrzymuje token z własną tożsamością oraz zawężonym zakresem uprawnień (scope). To fundament komunikacji maszyna-maszyna (M2M) i punkt wyjścia dla tak zwanych nieludzkie tożsamości^?nieludzkie tożsamości: tożsamości przypisane usługom, botom i agentom AI zamiast ludziom (Non-Human Identities) (NHI).

Delegacja uprawnień agentowi

Gdy agent działa w imieniu użytkownika, przekazywanie mu pełnego tokenu użytkownika jest ryzykowne. Standardowy token exchange (RFC 8693, wersja V2, w pełni wspierany i włączony domyślnie) pozwala wymienić token na węższy — ograniczony do konkretnej usługi (audience) i mniejszego zbioru uprawnień (downscoping). Dzięki temu agent otrzymuje dokładnie tyle dostępu, ile potrzebuje, i nic ponadto.

Keycloak jako serwer autoryzacji dla MCP

Standard Model Context Protocol^?Model Context Protocol: otwarty standard Anthropic do łączenia modeli i agentów AI z zewnętrznymi narzędziami i danymi (MCP), wprowadzony przez Anthropic, definiuje autoryzację opartą na OAuth 2.1. Serwer MCP pełni rolę OAuth resource server, a oddzielny serwer autoryzacji wystawia tokeny — i tę drugą rolę może przejąć Keycloak. Wymagane przez standard elementy, takie jak PKCE^?PKCE: Proof Key for Code Exchange — rozszerzenie OAuth 2.0 chroniące kod autoryzacyjny przed przechwyceniem; klient dowodzi parą weryfikator–wyzwanie, że to on rozpoczął logowanie, metadane serwera autoryzacji (RFC 8414) i dynamiczna rejestracja klientów (RFC 7591), należą do natywnych możliwości Keycloaka.

Najważniejsze ograniczenia i wyzwania

Największym wyzwaniem jest koszt operacyjny. Mimo darmowej licencji całkowity koszt posiadania (TCO) obejmuje infrastrukturę, dedykowany personel DevOps oraz regularne aktualizacje. Skalowanie wielowęzłowe opiera się na rozproszonej pamięci podręcznej Infinispan i protokole klastrowym JGroups, a poprawne utrzymanie stanu klastra w konfiguracji wysokiej dostępności należy do trudniejszych zadań operacyjnych.

System tej skali jest też atrakcyjnym celem ataków. W badanym okresie ujawniono istotne podatności, na przykład CVE-2024-4540, w której serwer błędnie zapisywał poufne parametry mechanizmu PAR jawnym tekstem w ciasteczku dostępnym dla klienta. Tego rodzaju incydenty wymuszają dyscyplinę w aktualizacjach. Z drugiej strony, projekt wycofał też starsze biblioteki integracyjne (tak zwane adaptery Javy), uznając, że natywne wsparcie OIDC i OAuth 2.0 we frameworkach takich jak Spring Security jest już wystarczające. Dla zespołów utrzymujących starsze integracje oznacza to konieczność migracji.

Dlaczego to jest istotne?

Keycloak jest dobrym przykładem dojrzałości modelu open-source w obszarze, w którym stawka jest wyjątkowo wysoka — bezpieczeństwo tożsamości. Tożsamość stała się nową granicą bezpieczeństwa. W świecie mikrousług, chmury i pracy zdalnej to nie zapora sieciowa, lecz poprawnie zweryfikowany token decyduje, kto i do czego ma dostęp. Keycloak pozwala zbudować tę warstwę raz, centralnie i zgodnie z otwartymi standardami, zamiast rozpraszać kruchą logikę bezpieczeństwa po dziesiątkach aplikacji.

Jego znaczenie rośnie szczególnie tam, gdzie suwerenność danych jest wymogiem, a nie preferencją — w sektorze finansowym, administracji publicznej i instytucjach rynków regulowanych. Możliwość trzymania całej bazy tożsamości na własnej infrastrukturze, bez zaufania do zagranicznego dostawcy chmurowego, jest argumentem nie do przecenienia. Migracja projektu do CNCF i przejście na lekki runtime Quarkus pokazują, że to nie skansen, lecz aktywnie modernizowana technologia. Dla każdego, kto buduje systemy wymagające logowania, Keycloak jest punktem odniesienia, który warto rozumieć, nawet jeśli ostatecznie wybierze się rozwiązanie SaaS.

Keycloak nie jest narzędziem lekkim ani bezobsługowym, ale pozostaje jednym z najsolidniejszych fundamentów tożsamości w ekosystemie cloud-native. Jego siła leży w połączeniu otwartości, zgodności ze standardami i dojrzałości, które razem czynią go domyślnym wyborem dla poważnych wdrożeń on-premise.

Źródła

• Keycloak — oficjalna dokumentacja projektu — link
• Wikipedia — Keycloak — link
• Cloud Native Computing Foundation — Keycloak project — link
• Red Hat — Red Hat build of Keycloak — link