OpenID Connect: co to jest, protokół uwierzytelniania i autoryzacji

Co to jest OpenID Connect?

OpenID Connect (OIDC) — to otwarty protokół uwierzytelniania zbudowany jako nakładka na OAuth 2.0. Standaryzuje to, czego brakowało w OAuth 2.0: weryfikację tożsamości użytkownika. Jeśli OAuth 2.0 odpowiada na pytanie „która aplikacja ma dostęp?„, to OIDC odpowiada na pytanie „kim dokładnie jest ten użytkownik?„.

Protokół używa ID Token — JSON Web Token (JWT), który zawiera zestaw claims: unikalny identyfikator podmiotu, email, imię, awatar, znaczniki czasu wydania i wygaśnięcia. Aplikacja kliencka może zweryfikować ID Token kryptograficznie — serwer podpisuje token za pomocą RS256 lub ES256, a klient sprawdza podpis za pomocą klucza publicznego uzyskanego przez JWKS endpoint.

Według danych Auth0, 2025, ponad 78% aplikacji mobilnych korzystających z zewnętrznego uwierzytelniania stosuje OIDC przez Google Sign-In lub Sign in with Apple. To czyni protokół standardem de facto dla social login i uwierzytelniania korporacyjnego.

Jak działa OpenID Connect

OpenID Connect definiuje kilka przepływów (flows) w zależności od typu klienta. Dla aplikacji mobilnych standardem jest Authorisation Code Flow z Proof Key for Code Exchange (PKCE) — zapewnia ochronę nawet przy braku client secret na urządzeniu.

Identity Provider i jego rola

Identity Provider (IdP) — to serwer, który wykonuje uwierzytelnianie użytkownika i wydaje tokeny. W ekosystemie OIDC IdP udostępnia dwa kluczowe endpointy: Authorisation Endpoint do logowania użytkownika oraz Token Endpoint do wymiany kodu na tokeny. Klient poznaje adresy tych endpointów przez Discovery URL — standardową ścieżkę /.well-known/openid-configuration, która zwraca dokument JSON z całą konfiguracją dostawcy.

Każdy IdP publikuje swój JWKS (JSON Web Key Set) — zestaw kluczy publicznych do weryfikacji podpisu ID Token. Klient buforuje te klucze i używa ich do weryfikacji każdego otrzymanego tokena bez odwoływania się do serwera.

Authorisation Code Flow z PKCE

Authorisation Code Flow — to proces trzystopniowy. Najpierw aplikacja mobilna generuje code verifier (losowy ciąg o długości 43–128 znaków) i jego hash — code challenge. Aplikacja otwiera przeglądarkę lub WebView z URL zawierającym client_id, redirect_uri, scope (openid profile email) i code challenge. Użytkownik wprowadza dane logowania na stronie IdP i potwierdza zgodę. IdP przekierowuje przeglądarkę z powrotem do aplikacji z authorisation code.

W drugim kroku aplikacja wysyła authorisation code, code verifier i client_id na Token Endpoint serwera. Serwer sprawdza code verifier względem zapisanego code challenge i zwraca ID Token, Access Token oraz opcjonalnie Refresh Token. W trzecim kroku aplikacja sprawdza ID Token: weryfikuje podpis przez JWKS, porównuje issuer (iss), audience (aud) i czas wygaśnięcia (exp). Jeśli weryfikacja się powiedzie — użytkownik jest uważany za uwierzytelnionego.

PKCE (Proof Key for Code Exchange) eliminuje podatność właściwą dla standardowego Authorisation Code Flow w klientach publicznych. Ponieważ aplikacja mobilna nie może bezpiecznie przechowywać client secret, osoba atakująca, która przechwyciła authorisation code, mogłaby wymienić go na tokeny. Code verifier rozwiązuje ten problem: nawet jeśli kod zostanie przechwycony, bez oryginalnego code verifier wymiana jest niemożliwa. OAuth Security Best Practices (RFC 9700) wymagają PKCE dla wszystkich klientów publicznych, w tym aplikacji mobilnych.

ID Token i Access Token

OpenID Connect zwraca dwa zasadniczo różne tokeny: ID Token i Access Token. ID Token — to zawsze JWT, który klient może odczytać i zweryfikować samodzielnie. Zawiera informacje o użytkowniku i służy do uwierzytelniania, a nie do dostępu do API.

Struktura ID Token

ID Token składa się z header, payload i signature, zakodowanych w Base64 i oddzielonych kropkami. Header zawiera alg (algorytm podpisu) i kid (identyfikator klucza). Payload zawiera obowiązkowe claims: iss (issuer — wystawca tokena), sub (subject — unikalne ID użytkownika), aud (audience — identyfikator klienta), exp (expiration), iat (issued at). Opcjonalnie — name, email, picture, locale.

Przykład zdekodowanego payload ID Token od Google:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Iwan Pietrow",
  "email": "ivan@example.com"
}

Access Token — to opaque token (dowolny ciąg znaków) lub JWT, który klient przekazuje w żądaniach API. W przeciwieństwie do ID Token, access token nie jest przeznaczony do odczytu przez klienta — jego format i zawartość są znane tylko serwerowi zasobów i serwerowi autoryzacji. Access Token ma scope — ograniczenie uprawnień dostępu — i krótki okres ważności, zwykle 15–60 minut.

Różnice między OpenID Connect a OAuth 2.0

OAuth 2.0 — to framework autoryzacji, który określa, jak aplikacja uzyskuje dostęp do zasobów użytkownika. OpenID Connect — to nakładka, która dodaje do tego procesu uwierzytelnianie. Kluczowa różnica: OAuth 2.0 nie określa formatu tokena i nie daje aplikacji sposobu na ustalenie, kto dokładnie wykonał żądanie.

Kiedy wybrać OpenID Connect

OpenID Connect jest niezbędny, gdy aplikacja musi rozpoznać użytkownika, a nie tylko uzyskać dostęp do jego danych. Jeśli używasz „Zaloguj się przez Google„ lub „Sign in with Apple„ — to OIDC. Jeśli twoja aplikacja wywołuje API stron trzecich w imieniu użytkownika bez potrzeby znajomości jego tożsamości — wystarczy czysty OAuth 2.0. Dla systemów korporacyjnych z Single Sign-On (SSO) wybór jest jednoznaczny: tylko OpenID Connect, ponieważ zapewnia standaryzowane wylogowanie i zarządzanie sesjami.

Implementacja OpenID Connect w aplikacjach mobilnych

Wdrożenie OpenID Connect w aplikacji mobilnej wymaga wyboru odpowiedniej biblioteki i prawidłowej konfiguracji przepływu. Dla Androida używa się credential manager (AndroidX Credentials) lub biblioteki AppAuth. Dla iOS — AuthenticationServices framework z ASWebAuthenticationSession.

Przykład kodu w Kotlin (Android)

Poniżej znajduje się przykład uruchomienia Authorisation Code Flow za pomocą biblioteki AppAuth-Android. Aplikacja tworzy żądanie autoryzacji, otwiera przeglądarkę w celu logowania użytkownika i obsługuje callback z tokenami.

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

Przykład kodu w Swift (iOS)

ASWebAuthenticationSession od Apple udostępnia wbudowaną przeglądarkę dla przepływu OIDC z obsługą SSO przez iCloud Keychain. Sesja jest uruchamiana z URL autoryzacji, a callback jest obsługiwany przez completion handler.

Przy wyborze biblioteki dla OpenID Connect uwzględnij obsługę PKCE od razu po wyjęciu z pudełka: AppAuth-Android i AppAuth-iOS obsługują PKCE domyślnie. Firebase Authentication używa OIDC pod maską dla Google Sign-In, Sign in with Apple i Microsoft — programista nie musi ręcznie implementować przepływu. Dla systemów korporacyjnych z własnym IdP (np. Keycloak lub Okta) AppAuth pozostaje standardowym wyborem z pełną kontrolą nad konfiguracją i obsługą błędów.

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()