OpenID Connect: mi ez, hitelesítési és engedélyezési protokoll

Mi az OpenID Connect?

OpenID Connect (OIDC) — egy nyílt hitelesítési protokoll, amely rétegként épül az OAuth 2.0 tetejére. Szabványosítja azt, ami hiányzott az OAuth 2.0-ból: a felhasználói személyazonosság ellenőrzését. Ha az OAuth 2.0 arra a kérdésre válaszol, hogy „melyik alkalmazás fér hozzá?„, akkor az OIDC arra a kérdésre válaszol, hogy „ki pontosan ez a felhasználó?„.

A protokoll ID Token — JSON Web Token (JWT) használ, amely claims-ek halmazát tartalmazza: az alany egyedi azonosítója, email, név, avatár, kiadási és lejárati időbélyegek. A kliensalkalmazás kriptográfiailag ellenőrizheti az ID Token-t — a szerver aláírja a tokent RS256 vagy ES256 segítségével, a kliens pedig ellenőrzi az aláírást a JWKS végponton keresztül kapott nyilvános kulccsal.

A Auth0, 2025 adatai szerint a külső hitelesítést használó mobilalkalmazások több mint 78%-a alkalmazza az OIDC-t a Google Sign-In vagy a Sign in with Apple segítségével. Ez a protokollt de facto szabvánnyá teszi a közösségi bejelentkezés és a vállalati hitelesítés terén.

Hogyan működik az OpenID Connect

OpenID Connect több folyamatot (flow) határoz meg a kliens típusától függően. Mobilalkalmazások esetében a szabvány az Authorisation Code Flow Proof Key for Code Exchange (PKCE) kiegészítéssel — védelmet biztosít még client secret nélkül is az eszközön.

Identity Provider és szerepe

Identity Provider (IdP) — az a szerver, amely elvégzi a felhasználó hitelesítését és tokeneket bocsát ki. Az OIDC ökoszisztémában az IdP két kulcsfontosságú végpontot biztosít: Authorisation Endpoint a felhasználó bejelentkezéséhez és Token Endpoint a kód tokenekre cseréléséhez. A kliens ezen végpontok címeit a Discovery URL-en keresztül ismeri meg — a szabványos /.well-known/openid-configuration elérési utat, amely egy JSON dokumentumot ad vissza a szolgáltató teljes konfigurációjával.

Minden IdP közzéteszi saját JWKS (JSON Web Key Set) készletét — nyilvános kulcsok halmazát az ID Token aláírásának ellenőrzéséhez. A kliens eltárolja ezeket a kulcsokat, és minden fogadott token ellenőrzéséhez használja anélkül, hogy a szerverhez fordulna.

Authorisation Code Flow PKCE-vel

Authorisation Code Flow — egy háromlépéses folyamat. Először a mobilalkalmazás generál egy code verifier-t (43–128 karakter hosszú véletlenszerű sztring) és annak hash-ét — code challenge-et. Az alkalmazás megnyit egy böngészőt vagy WebView-t egy URL-lel, amely client_id-t, redirect_uri-t, scope-ot (openid profile email) és code challenge-et tartalmaz. A felhasználó megadja a hitelesítő adatait az IdP oldalán, és megerősíti a hozzájárulást. Az IdP visszairányítja a böngészőt az alkalmazásba egy authorisation code-dal.

A második lépésben az alkalmazás elküldi az authorisation code-ot, code verifier-t és client_id-t a szerver Token Endpoint-jára. A szerver ellenőrzi a code verifier-t az eltárolt code challenge-hez képest, és visszaadja az ID Token-t, Access Token-t és opcionálisan a Refresh Token-t. A harmadik lépésben az alkalmazás ellenőrzi az ID Token-t: érvényesíti az aláírást a JWKS-en keresztül, ellenőrzi az issuer (iss), audience (aud) és lejárati idő (exp) mezőket. Ha az ellenőrzés sikeres — a felhasználó hitelesítettnek tekintendő.

A PKCE (Proof Key for Code Exchange) kiküszöböli a szabványos Authorisation Code Flow-ban rejlő sebezhetőséget a nyilvános klienseknél. Mivel a mobilalkalmazás nem tudja biztonságosan tárolni a client secret-et, egy támadó, aki elfogta az authorisation code-ot, tokenekre cserélhette azt. A Code verifier megoldja ezt a problémát: még ha a kódot el is fogják, az eredeti code verifier nélkül a csere lehetetlen. Az OAuth Security Best Practices (RFC 9700) megköveteli a PKCE-t minden nyilvános kliens számára, beleértve a mobilalkalmazásokat is.

ID Token és Access Token

Az OpenID Connect két alapvetően különböző tokent ad vissza: ID Token és Access Token. Az ID Token — mindig JWT, amelyet a kliens önállóan elolvashat és ellenőrizhet. Információkat tartalmaz a felhasználóról, és hitelesítésre használatos, nem API-hozzáférésre.

Az ID Token felépítése

ID Token egy header-ből, payload-ból és signature-ből áll, amelyek Base64-ben vannak kódolva és pontokkal elválasztva. A header tartalmazza az alg-t (aláírási algoritmus) és a kid-t (kulcsazonosító). A payload kötelező claims-eket tartalmaz: iss (issuer — a token kibocsátója), sub (subject — a felhasználó egyedi ID-ja), aud (audience — a kliens azonosítója), exp (expiration), iat (issued at). Opcionálisan — name, email, picture, locale.

Példa egy Google-tól származó ID Token dekódolt payload-jára:

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

Access Token — egy átlátszatlan token (tetszőleges sztring) vagy JWT, amelyet a kliens API-kérésekben továbbít. Ellentétben az ID Token-nel, az access token nem a kliens általi olvasásra készült — formátuma és tartalma csak az erőforrás-szerver és az engedélyezési szerver számára ismert. Az Access Token rendelkezik scope-pal — hozzáférési jogok korlátozása — és rövid élettartammal, általában 15–60 perc.

Az OpenID Connect és OAuth 2.0 közötti különbségek

OAuth 2.0 — egy engedélyezési keretrendszer, amely meghatározza, hogy az alkalmazás hogyan fér hozzá a felhasználó erőforrásaihoz. OpenID Connect — egy réteg, amely hitelesítést ad ehhez a folyamathoz. A kulcsfontosságú különbség: az OAuth 2.0 nem határozza meg a token formátumát, és nem ad az alkalmazásnak módot arra, hogy megtudja, ki pontosan ki küldte a kérést.

Mikor válasszuk az OpenID Connect-et

Az OpenID Connect akkor szükséges, ha az alkalmazásnak fel kell ismernie a felhasználót, nem csak hozzáférést kell kapnia az adataihoz. Ha „Bejelentkezés Google-lal„ vagy „Sign in with Apple„ funkciót használ — ez OIDC. Ha az alkalmazás egy harmadik féltől származó API-t hív a felhasználó nevében anélkül, hogy tudnia kellene a személyazonosságát — tiszta OAuth 2.0 is elegendő. Vállalati rendszerek esetén Single Sign-On (SSO) funkcióval a választás egyértelmű: csak OpenID Connect, mivel szabványosított kijelentkezést és munkamenet-kezelést biztosít.

OpenID Connect implementálása mobilalkalmazásokban

Az OpenID Connect mobilalkalmazásba való integrálása megfelelő könyvtár kiválasztását és a folyamat helyes konfigurálását igényli. Android esetén a credential manager (AndroidX Credentials) vagy az AppAuth könyvtár használatos. iOS esetén — az AuthenticationServices keretrendszer ASWebAuthenticationSession funkcióval.

Kód példa Kotlin nyelven (Android)

Az alábbi példa az Authorisation Code Flow elindítását mutatja be az AppAuth-Android könyvtár segítségével. Az alkalmazás létrehoz egy engedélyezési kérést, megnyit egy böngészőt a felhasználó bejelentkezéséhez, és feldolgozza a callback-et a tokenekkel.

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)
        }
    }
}

Kód példa Swift nyelven (iOS)

Az Apple ASWebAuthenticationSession segítségével beépített böngészőt biztosít az OIDC folyamathoz SSO támogatással az iCloud Keychain-en keresztül. A munkamenet az engedélyezési URL-lel indul, a callback pedig a completion handler-en keresztül kerül feldolgozásra.

Az OpenID Connect könyvtár kiválasztásakor vegye figyelembe a beépített PKCE támogatást: az AppAuth-Android és AppAuth-iOS alapértelmezés szerint támogatja a PKCE-t. A Firebase Authentication a motorháztető alatt OIDC-t használ a Google Sign-In, Sign in with Apple és Microsoft szolgáltatásokhoz — a fejlesztőnek nem kell manuálisan implementálnia a folyamatot. Saját IdP-vel rendelkező vállalati rendszerekhez (pl. Keycloak vagy Okta) az AppAuth marad a szabványos választás, teljes kontrollal a konfiguráció és hibakezelés felett.

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()