OpenID Connect — jak protokół tożsamości przejął Internet

Czym jest OpenID Connect i skąd się wziął

OpenID Connect (OIDC) to otwarty protokół uwierzytelniania opublikowany 26 lutego 2014 roku przez OpenID Foundation. Jego misja była prosta, ale przez lata odkładana: dać programistom standaryzowany sposób na weryfikację tożsamości użytkownika w aplikacji internetowej — bez przechowywania haseł i bez wymyślania własnych kół na nowo.

Zanim OIDC wkroczyło na scenę, twórcy aplikacji często sięgali po OAuth 2.0 jako narzędzie do logowania. Problem w tym, że OAuth 2.0 zaprojektowano jako mechanizm autoryzacji — nie uwierzytelniania. Nie definiował, kim jest zalogowany użytkownik — definiował wyłącznie, do czego ma dostęp. OIDC wypełnia tę lukę, dokładając do struktury OAuth 2.0 podpisany kryptograficznie token tożsamości — ID Token — i ustandaryzowany endpoint do pobierania danych profilowych.

Dziś OIDC napędza logowanie przez Google, Microsoft, Apple, GitHub i setki enterprise'owych systemów SSO^?SSO: Single Sign-On — mechanizm jednorazowego logowania: użytkownik uwierzytelnia się raz i uzyskuje dostęp do wielu powiązanych aplikacji bez ponownego podawania hasła. Jest fundamentem każdej aplikacji, która wyświetla przycisk „Zaloguj z...”.

OAuth 2.0 a OIDC — autoryzacja to nie uwierzytelnianie

Różnica między tymi dwoma standardami jest fundamentalna i często niedoceniana. OAuth 2.0 odpowiada na pytanie: „Do czego ta aplikacja ma dostęp?”. OIDC odpowiada na pytanie: „Kim jest ten użytkownik?”.

OAuth 2.0 wystawia Access Token — przepustkę do API. Token ten jest zazwyczaj nieprzejrzysty dla aplikacji klienckiej: wie ona, że go ma, ale nie wie z góry, kogo reprezentuje. Klasyczna metafora to kluczyk parkingowy — pozwala zaparkować auto, nie otwiera bagażnika i nie zdradza, kto jest właścicielem.

OIDC dodaje do tego ekwipunku ID Token w formacie JWT^?JWT: JSON Web Token — samodzielnie weryfikowalny token z podpisem kryptograficznym, przenoszący oświadczenia o tożsamości. Ten token jest podpisany cyfrowo i zawiera weryfikowalne oświadczenia o użytkowniku: jego unikalny identyfikator, moment logowania, wystawcę tokenu i odbiorcę. Aplikacja może zweryfikować podpis kryptograficzny i lokalnie, bez żadnego dodatkowego żądania sieciowego, potwierdzić tożsamość osoby, która się zalogowała.

Trzy role w ekosystemie OIDC

Każdy przepływ OIDC angażuje trzy strony o precyzyjnie zdefiniowanych rolach, bezpośrednio odpowiadających rolom z protokołu OAuth 2.0.

Użytkownik końcowy

Osoba inicjująca logowanie. Hasło wpisuje wyłącznie na stronie dostawcy tożsamości — serwis, do którego chce uzyskać dostęp, nie uczestniczy w tym etapie i nie ma dostępu do żadnych poświadczeń. Po pomyślnym uwierzytelnieniu użytkownik jest automatycznie przekierowany z powrotem do serwisu.

Jednostka uzależniona (Relying Party)

Twoja aplikacja — strona internetowa, serwis mobilny lub API — która potrzebuje wiedzieć, kim jest zalogowany użytkownik, ale zamiast przechowywać hasła samodzielnie, deleguje to zadanie zewnętrznemu dostawcy tożsamości. Stąd nazwa: relying — dosłownie „polegasąca na kimś innym”. żeby dostawca w ogóle obsługiwał logowania dla danej aplikacji, ta musi się u niego wcześniej zarejestrować — np. w panelu Google Cloud lub Auth0. Efektem rejestracji jest unikalny identyfikator (client_id), który aplikacja dołącza do każdego żądania logowania, żeby dostawca wiedział, kto pyta.

Dostawca OpenID (OpenID Provider)

Serwer autoryzacji zgodny ze specyfikacją OIDC i OAuth 2.0. Weryfikuje tożsamość użytkownika, uzyskuje jego zgodę i wystawia tokeny. Przykłady: Google Identity, Microsoft Entra, Auth0, Keycloak.

{
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "scopes_supported": ["openid", "email", "profile"],
  ...
}

ID Token — serce protokołu

ID Token jest tym, co odróżnia OIDC od samego OAuth 2.0. Zawsze ma format JSON Web Token (JWT) i jest kryptograficznie podpisany przez dostawcę tożsamości. Dzięki temu aplikacja kliencka może zweryfikować jego integralność bez kontaktu z serwerem.

Minimalny poprawny ID Token zawiera kilka obowiązkowych oświadczeń:

• iss (issuer) — identyfikator wystawcy, np. https://accounts.google.com
• sub (subject) — globalnie unikalny, niezmienny identyfikator użytkownika u danego wystawcy
• aud (audience) — client_id aplikacji, dla której token został wystawiony
• exp (expiration) — czas wygaśnięcia jako znacznik UNIX
• iat (issued at) — czas wystawienia jako znacznik UNIX

Para iss + sub — stabilna tożsamość

Szczególnie istotna jest para iss + sub. To ona stanowi globalnie unikalną, stabilną tożsamość użytkownika. Adres e-mail czy nazwa użytkownika mogą się zmienić — sub nigdy. Opieranie identyfikacji użytkownika na e-mailu zamiast na sub to klasyczny błąd architektury, który prowadzi do trudnych do debugowania problemów po migracji kont.

Nonce — ochrona przed replay attacks

Dla wzmocnienia bezpieczeństwa OIDC wykorzystuje też oświadczenie nonce — losową wartość generowaną przez aplikację kliencką przed wysłaniem żądania, zwracaną następnie w tokenie. Weryfikacja nonce chroni przed atakami powtórzenia sesji (replay attacks).

UserInfo Endpoint — gdzie mieszka profil użytkownika

ID Token celowo zawiera minimum danych tożsamości. Bogaty profil użytkownika — imię, nazwisko, zdjęcie, adres e-mail, numer telefonu, adres zamieszkania — dostępny jest przez dedykowany, chroniony endpoint: UserInfo Endpoint.

Aby pobrać dane profilowe, aplikacja kliencka wysyła żądanie HTTP GET do tego endpointu, dołączając w nagłówku Access Token typu Bearer. W odpowiedzi otrzymuje strukturę JSON z oświadczeniami (claims) — lub JWT, jeśli dostawca tak skonfigurował.

Ilość zwracanych danych zależy od zakresów (scopes) zażądanych podczas inicjowania autoryzacji:

• openid — obowiązkowy dla każdego przepływu OIDC, zapewnia minimalną tożsamość
• profile — imię, nazwisko, zdjęcie, locale, data aktualizacji
• email — adres e-mail i flaga email_verified
• phone — numer telefonu i flaga phone_number_verified
• address — dane adresowe

Ważna zasada bezpieczeństwa: aplikacja kliencka musi zweryfikować, że sub z UserInfo Endpoint jest zgodny z sub w uprzednio otrzymanym ID Tokenie. To zabezpieczenie przed podstawieniem obcego tokenu.

Microsoft i inne duże platformy sugerują minimalizowanie wywołań UserInfo Endpoint tam, gdzie żądane dane można zawrzeć bezpośrednio w ID Tokenie jako oświadczenia opcjonalne (optional claims). Każde dodatkowe żądanie sieciowe to opóźnienie — warto je eliminować, gdy dane i tak są dostępne w podpisanym JWT.

Przepływy autoryzacji — Authorization Code, PKCE, Implicit i Hybrid

OIDC definiuje trzy podstawowe przepływy pozyskiwania tokenów, determinowane parametrem response_type w żądaniu autoryzacji.

Authorization Code Flow

To fundamentalny i najwyżej rekomendowany przepływ. Po uwierzytelnieniu użytkownika dostawca OP nie oddaje tokenów bezpośrednio do przeglądarki — zamiast tego wystawia jednorazowy, krótkotrwały Kod autoryzacyjny. Aplikacja serwer-side wymienia ten kod na tokeny bezpośrednio z endpointem tokenów (back-channel), dołączając własne poświadczenia (client_secret). Przeglądarka użytkownika nigdy nie widzi surowych tokenów.

Authorization Code Flow z PKCE

PKCE^?PKCE: Proof Key for Code Exchange (RFC 7636) — mechanizm kryptograficzny zabezpieczający wymianę kodu autoryzacyjnego bez konieczności użycia statycznego client_secret to ewolucja poprzedniego przepływu dla aplikacji, które nie mogą bezpiecznie przechować client_secret — aplikacji SPA (React, Vue, Angular) i aplikacji mobilnych. Przed każdym logowaniem klient generuje losowy code_verifier i oblicza z niego skrót SHA-256 (code_challenge). Skrót wysyła do dostawcy przy żądaniu autoryzacji. Przy wymianie kodu na token klient przesyła pierwotny code_verifier — dostawca sam oblicza skrót i weryfikuje zgodność. Atakujący, który przechwyci kod autoryzacyjny, nie może go wymienić na token bez znajomości code_verifier. Standardy OAuth 2.1 formalizują PKCE jako obowiązkowy wzorzec dla wszystkich typów aplikacji.

Implicit Flow

To historyczny relikt. Po uwierzytelnieniu dostawca oddaje tokeny bezpośrednio do przeglądarki w przekierowaniu URL — front-channel delivery. Tokeny mogą trafiać do historii przeglądarki, logów serwerów HTTP i być podatne na wycieki XSS. Refresh Token jest w tym przepływie całkowicie zakazany.

Hybrid Flow

Łączy elementy obu powyższych — część tokenów dostarczona jest front-channel (np. ID Token), część back-channel (Access Token, Refresh Token). Stosowany w złożonych scenariuszach korporacyjnych, gdzie frontend potrzebuje szybkiego dostępu do tożsamości, a backend do pełnych uprawnień API. Wymaga restrykcyjnej walidacji parametrów weryfikujących (m.in. c_hash, nonce).

Implementacje i biblioteki

OpenID Foundation certyfikuje biblioteki klienckie i dostawców tożsamości, co zapewnia gwarancję pełnej zgodności ze specyfikacją. Samodzielna implementacja parsowania JWT, weryfikacji podpisów kryptograficznych i obsługi JWKS jest kosztowna i ryzykowna — warto korzystać z dojrzałych, certyfikowanych bibliotek.

Kluczowe biblioteki według platformy:

• JavaScript/TypeScript SPA — oidc-client-ts (certyfikowana, TypeScript, PKCE)
• Node.js backend — openid-client (certyfikowana, back-channel, FAPI)
• Python — Authlib (integracje z Django i Flask), pyoidc (certyfikowana)
• Java/Spring — Spring Security OAuth2 Client, com.nimbusds/oauth2-oidc-sdk
• .NET/C# — IdentityModel, Microsoft.Identity.Client (MSAL)
• Go — coreos/go-oidc, zitadel/oidc (certyfikowana)

Standardowy punkt startowy dla każdej biblioteki to /.well-known/openid-configuration — dokument discovery, który automatycznie dostarcza adresy wszystkich endpointów i kluczy publicznych. Zmiana dostawcy (np. z Auth0 na Keycloak) sprowadza się często do modyfikacji jednej linii konfiguracji.

OIDC w erze agentów AI — tożsamość nieosobowa

Przez dekadę OIDC weryfikował tożsamość ludzi: użytkownik wpisywał hasło, dostawca tożsamości wystawiał ID Token, aplikacja wiedziała, kto się zalogował. Era agentów AI ten model czyni niewystarczającym.

Dzisiejsze systemy AI działają bez przeglądarki i bez hasła. Asystent analityczny przegląda dane finansowe, orkiestrator wysyła polecenia do dziesiątek narzędzi i interfejsów API, subagent przetwarza dokumenty w tle — żadna z tych operacji nie przechodzi przez ekran logowania. Raporty branżowe wskazują, że stosunek tożsamości maszynowych do ludzkich przekroczył proporcję 82:1. Agent AI jest dziś pierwszorzędnym podmiotem bezpieczeństwa, nie anonimowym serwisem backendowym.

Problem z tradycyjnym podejściem polega na tym, że jeśli kilka agentów współdzieli jedno konto serwisowe i jeden client_secret, logi systemowe przestają mówić, który agent podjął jaką decyzję, w czyim imieniu i na podstawie jakiego uprawnienia. Każda anomalia staje się niemożliwa do przypisania — a tym samym niemożliwa do zbadania.

Właściwa architektura przypisuje agentowi unikatową, efemeryczną^?efemeryczną: tymczasową — ważną tylko przez czas jednej sesji lub zadania. Po jego zakończeniu tożsamość jest usuwana. tożsamość na czas sesji lub zadania, ogranicza zakres dostępu do minimum (zasada Least Privilege), stosuje dostęp Just-In-Time i eliminuje długowieczne, współdzielone klucze. Agent zarejestrowany jako klient OIDC otrzymuje krótkoważne tokeny JWT sfederowane z dostawcą chmurowym — i nie zna żadnych globalnych sekretów.

Model Context Protocol i autoryzacja

Model Context Protocol (MCP), opublikowany przez Anthropic pod koniec 2024 roku, stał się de facto standardem integrującym modele językowe z zewnętrznymi narzędziami: bazami danych, API, systemami plików i rejestrami korporacyjnymi. Z perspektywy bezpieczeństwa MCP jest warstwą transportową — fundamentem uwierzytelniania tej warstwy jest OAuth 2.1 z obowiązkowym PKCE.

Architektura ról w MCP

• MCP Server pełni rolę OAuth 2.1 Resource Server — chroni zasoby i wymaga ważnego Bearer tokena przy każdym żądaniu.
• MCP Client / agent AI działa jako OAuth 2.1 Client — żąda dostępu w imieniu użytkownika lub we własnym imieniu.
• Serwer autoryzacyjny (np. Keycloak, Auth0, Microsoft Entra) zarządza zgodami i wydaje tokeny.

Przepływ autoryzacji dla zdalnego (HTTP) serwera MCP przebiega następująco. Niezalogowany klient otrzymuje HTTP 401 Unauthorized z nagłówkiem WWW-Authenticate wskazującym dokument metadanych (RFC 9728). Klient identyfikuje serwer autoryzacyjny i inicjuje przepływ Authorization Code z PKCE. Po udzieleniu zgody przez użytkownika każde kolejne żądanie zawiera Bearer token — serwer MCP weryfikuje podpis, wystawcę (iss), ważność (exp) i odbiorcę (aud).

Lokalne serwery MCP komunikujące się przez STDIO^?STDIO: Standard Input/Output — mechanizm komunikacji między procesami przez standardowe wejście i wyjście systemu operacyjnego. Używany przez lokalne serwery MCP działające w tym samym środowisku co klient. często polegają na zmiennych środowiskowych, co jest dopuszczalne w izolowanym środowisku deweloperskim. W środowiskach produkcyjnych i korporacyjnych obowiązuje pełna ścieżka OAuth 2.1.

Łańcuchy delegacji — kto naprawdę działa?

Gdy agent AI wykonuje operację na bazie danych, serwer docelowy widzi żądanie z tokenem. Kluczowe pytanie: w czyim imieniu działa ten agent? Czy ma jawne, cofalne, ograniczone uprawnienie od konkretnego użytkownika — czy może korzysta z globalnego klucza serwisowego, który niemożliwy jest do przypisania nikomu?

Odpowiedź daje roboczy draft IETF: OAuth 2.0 On-Behalf-Of User Authorization for AI Agents. Standard wprowadza dwa nowe parametry:

Parametry OBO

• requested_actor^?requested_actor: Parametr OAuth identyfikujący agenta AI, który ma działać w imieniu użytkownika — wyświetlany na ekranie zgody, by użytkownik wiedział, komu udziela dostępu — przesyłany do endpointu autoryzacji. Wskazuje konkretnego agenta AI, któremu użytkownik świadomie udziela dostępu, i wyświetlany jest na ekranie zgody.
• actor_token^?actor_token: JWT kryptograficznie identyfikujący agenta AI w przepływie On-Behalf-Of — serwer weryfikuje go przed wystawieniem tokenu delegowanego — JWT identyfikujący agenta, przesyłany do endpointu tokenów. Serwer autoryzacyjny porównuje sub z actor_token z zatwierdzonym requested_actor przed wystawieniem tokenu.

Trzy tożsamości w jednym tokenie

1. User (Subject) — właściciel zasobu, w którego imieniu działa agent.
2. Client (Delegator) — aplikacja, przez którą użytkownik zainicjował działanie.
3. Agent (Actor) — autonomiczne oprogramowanie LLM wykonujące operację.

Dla wieloetapowych łańcuchów (Agent A zleca Agentowi B) stosuje się OAuth 2.0 Token Exchange (RFC 8693). Oświadczenie act wbudowane w JWT śledzi pełną historię delegacji — każdy krok jest kryptograficznie powiązany z poprzednim. Serwer finansowy może sprawdzić: czy algorytm analizujący bilans otrzymał wyraźne zezwolenie od Głównego Księgowego, z jakim zakresem i na jak długo?

OpenID Connect for Agents (OIDC-A)

Standardowy OIDC odpowiada na pytanie: kim jest użytkownik? W świecie agentów AI potrzeba odpowiedzi na nowe pytanie: czym jest ten agent i czy można mu zaufać? Wersja modelu LLM, dostawca i konfiguracja środowiska wykonawczego to atrybuty bezpieczeństwa, nie tylko metadane.

Na stan dzisiejszy (czerwiec 2026) OpenID Foundation prowadzi prace nad OpenID Connect for Agents (OIDC-A) 1.0 — rozszerzeniem, które nadaje agentom AI weryfikowalną tożsamość techniczną, komplementarną wobec standardowych tożsamości ludzkich.

Nowe oświadczenia agenta

OIDC-A definiuje nowe claims opisujące konfigurację kognitywną^?konfiguracja kognitywna: zespół parametrów opisujących, czym jest dany agent AI: jakiego modelu używa, kto go dostarcza i jak jest skonfigurowany. Analogicznie do odcisku palca modelu — serwer może go zweryfikować przed udzieleniem dostępu.: agent_type, agent_model (np. llama-3-internal) i agent_provider. Zamiast adresu IP czy identyfikatora usługi podmiot ufający (RP) widzi, z jakiego modelu i środowiska pochodzi żądanie.

Atestacja integralności

Pole agent_attestation zawiera kryptograficzny dowód zgodny z IETF RATS i Entity Attestation Tokens (EAT). Potwierdza, że instancja LLM nie została zmodyfikowana po stronie dostawcy chmurowego — podmiot ufający może weryfikować podpisy, status platformy i świeżość atestacji.

Śledzenie kontekstu delegacji

Pola delegation_chain i delegation_purpose wbudowane w token umożliwiają zagnieżdżoną autoryzację on-behalf-of dla złożonych systemów wieloagentowych. Serwer finansowy może wymusić politykę warunkową: zezwalaj na odczyt danych bilansowych wyłącznie agentom z atestowanym, wewnętrznie hostowanym modelem bez dostępu do publicznego Internetu.

OIDC-A pozostaje roboczym standardem, lecz kierunek jest jasny: bezpieczeństwo systemów AI-native wymaga weryfikacji nie tylko tego, kto loguje się do systemu, lecz także tego, co loguje się w jego imieniu.

Złote reguły bezpiecznego OIDC w 2024 roku

Dobre wdrożenie OIDC to nie tylko wybór właściwego przepływu. Bezpieczeństwo wymaga przestrzegania kilku zasad:

1. Zawsze stosuj Authorization Code Flow z PKCE — dla aplikacji webowych, SPA i mobilnych bez wyjątku. Implicit Flow jest zdeprecjonowany i nie powinien pojawiać się w nowych wdrożeniach.
2. Identyfikuj użytkowników wyłącznie przez parę iss + sub. Adres e-mail jest mutowalny — sub jest stały.
3. Weryfikuj nonce w ID Tokenie przy każdym logowaniu, aby chronić się przed atakami powtórzenia sesji.
4. Rozważ tokeny powiązane z nadawcą (DPoP lub mTLS) dla krytycznych systemów API, aby eliminować ryzyko użycia skradzionych tokenów przez nieautoryzowane klienty.
5. Stosuj rotację Refresh Tokenów — po każdym użyciu Refresh Token jest unieważniany i zastępowany nowym. To uniemożliwia trwałe wykorzystanie przejętego tokenu poza ramami aktywnej sesji.

OpenID Connect to dziś nieodłączny element infrastruktury tożsamości. OAuth 2.0 odpowiada na pytanie „do czego masz dostęp”, OIDC na pytanie „kim jesteś” — razem tworzą fundament nowoczesnego bezpieczeństwa aplikacji.

Źródła

• openid.net — OpenID Connect Core 1.0 — link
• IETF — RFC 6749: The OAuth 2.0 Authorization Framework — link
• IETF — RFC 7636: Proof Key for Code Exchange by OAuth Public Clients — link
• IETF — RFC 9700: OAuth 2.0 Security Best Current Practice — link
• IETF — RFC 8693: OAuth 2.0 Token Exchange — link
• IETF — RFC 9728: OAuth 2.0 Protected Resource Metadata — link
• Microsoft — Identity Platform and OpenID Connect protocol — link
• openid.net — OIDC Certified Implementations — link
• modelcontextprotocol.io — MCP Authorization Specification — link
• IETF Draft — OAuth 2.0 On-Behalf-Of User Authorization for AI Agents — link