OpenID Connect: Was es ist, Authentifizierungs- und Autorisierungsprotokoll

Was ist OpenID Connect?

OpenID Connect (OIDC) ist ein offenes Authentifizierungsprotokoll, das als Erweiterung auf OAuth 2.0 aufbaut. Es standardisiert, was OAuth 2.0 fehlte: die Überprüfung der Benutzeridentität. Wenn OAuth 2.0 die Frage „Welche Anwendung hat Zugriff?“ beantwortet, dann beantwortet OIDC „Wer genau ist dieser Benutzer?“.

Das Protokoll verwendet ein ID Token — ein JSON Web Token (JWT), das eine Reihe von Claims enthält: eine eindeutige Subjektkennung, E-Mail, Name, Avatar, Ausstellungs- und Ablaufzeitstempel. Die Client-Anwendung kann das ID Token kryptografisch verifizieren — der Server signiert das Token mit RS256 oder ES256, und der Client überprüft die Signatur mit dem über den JWKS-Endpoint bezogenen öffentlichen Schlüssel.

Laut Auth0, 2025 verwenden über 78% der mobilen Anwendungen, die Drittanbieter-Authentifizierung nutzen, OIDC über Google Sign-In oder Sign in with Apple. Dies macht das Protokoll zum De-facto-Standard für Social Login und Unternehmensauthentifizierung.

Wie OpenID Connect funktioniert

OpenID Connect definiert mehrere Flows je nach Client-Typ. Für mobile Anwendungen ist der Standard der Authorization Code Flow mit Proof Key for Code Exchange (PKCE) — er bietet Sicherheit auch ohne ein Client Secret auf dem Gerät.

Identity Provider und seine Rolle

Ein Identity Provider (IdP) ist ein Server, der Benutzer authentifiziert und Tokens ausgibt. Im OIDC-Ökosystem stellt der IdP zwei wichtige Endpoints bereit: den Authorization Endpoint für die Benutzeranmeldung und den Token Endpoint zum Austausch des Codes gegen Tokens. Der Client findet die Adressen dieser Endpoints über die Discovery URL — den Standardpfad /.well-known/openid-configuration, der ein JSON-Dokument mit der gesamten Provider-Konfiguration zurückgibt.

Jeder IdP veröffentlicht seinen JWKS (JSON Web Key Set) — eine Sammlung öffentlicher Schlüssel zur Überprüfung der ID Token-Signatur. Der Client speichert diese Schlüssel zwischen und verwendet sie, um jedes empfangene Token ohne Serverkontakt zu verifizieren.

Authorization Code Flow mit PKCE

Der Authorization Code Flow ist ein dreistufiger Prozess. Zunächst generiert die mobile Anwendung einen Code Verifier (eine zufällige Zeichenfolge von 43–128 Zeichen) und dessen Hash — den Code Challenge. Die Anwendung öffnet einen Browser oder WebView mit einer URL, die client_id, redirect_uri, scope (openid profile email) und Code Challenge enthält. Der Benutzer gibt auf der IdP-Seite Anmeldedaten ein und bestätigt die Zustimmung. Der IdP leitet den Browser mit einem Authorization Code zurück zur Anwendung.

Im zweiten Schritt sendet die Anwendung den Authorization Code, Code Verifier und client_id an den Token Endpoint des Servers. Der Server überprüft den Code Verifier gegen den gespeicherten Code Challenge und gibt ein ID Token, Access Token und optional ein Refresh Token zurück. Im dritten Schritt überprüft die Anwendung das ID Token: Sie validiert die Signatur gegen JWKS, prüft den Issuer (iss), die Audience (aud) und die Ablaufzeit (exp). Wenn die Überprüfung erfolgreich ist, gilt der Benutzer als authentifiziert.

PKCE (Proof Key for Code Exchange) beseitigt eine Schwachstelle, die dem Standard-Authorization Code Flow bei öffentlichen Clients innewohnt. Da eine mobile Anwendung kein Client Secret sicher speichern kann, könnte ein Angreifer, der den Authorization Code abfängt, diesen gegen Tokens eintauschen. Der Code Verifier löst dieses Problem: Selbst wenn der Code abgefangen wird, ist ein Austausch ohne den ursprünglichen Code Verifier unmöglich. OAuth Security Best Practices (RFC 9700) schreiben PKCE für alle öffentlichen Clients vor, einschließlich mobiler Anwendungen.

ID Token und Access Token

OpenID Connect gibt zwei grundlegend verschiedene Tokens zurück: das ID Token und das Access Token. Das ID Token ist immer ein JWT, das der Client selbst lesen und verifizieren kann. Es enthält Benutzerinformationen und wird für die Authentifizierung verwendet, nicht für den API-Zugriff.

Struktur des ID Tokens

Das ID Token besteht aus einem Header, Payload und einer Signatur, die in Base64 kodiert und durch Punkte getrennt sind. Der Header enthält alg (Signaturalgorithmus) und kid (Schlüsselidentifikator). Der Payload enthält erforderliche Claims: iss (Issuer), sub (Subject — eindeutige Benutzer-ID), aud (Audience — Client-Kennung), exp (Expiration), iat (Issued At). Optionale Claims sind name, email, picture, locale.

Beispiel eines decodierten ID Token-Payloads von Google:

{
  "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"
}

Das Access Token ist ein undurchsichtiges Token (beliebige Zeichenfolge) oder JWT, das der Client in API-Anfragen übergibt. Im Gegensatz zum ID Token ist das Access Token nicht dafür vorgesehen, vom Client gelesen zu werden — sein Format und Inhalt sind nur dem Ressourcenserver und dem Autorisierungsserver bekannt. Das Access Token hat einen Scope — eine Berechtigungseinschränkung — und eine kurze Lebensdauer, typischerweise 15–60 Minuten.

Unterschiede zwischen OpenID Connect und OAuth 2.0

OAuth 2.0 ist ein Autorisierungsframework, das definiert, wie eine Anwendung Zugriff auf Benutzerressourcen erhält. OpenID Connect ist eine Erweiterung, die diesem Prozess Authentifizierung hinzufügt. Der Hauptunterschied: OAuth 2.0 definiert kein Token-Format und gibt der Anwendung keine Möglichkeit zu erfahren, wer genau die Anfrage gestellt hat.

Wann OpenID Connect wählen

OpenID Connect ist erforderlich, wenn die Anwendung den Benutzer identifizieren muss, nicht nur auf seine Daten zugreifen will. Wenn Sie „Mit Google anmelden“ oder „Mit Apple anmelden“ verwenden — das ist OIDC. Wenn Ihre Anwendung im Namen des Benutzers eine Drittanbieter-API aufruft, ohne dessen Identität zu benötigen — reicht reines OAuth 2.0 aus. Für Unternehmenssysteme mit Single Sign-On (SSO) ist die Wahl klar: nur OpenID Connect, da es standardisiertes Logout und Session-Management bietet.

Implementierung von OpenID Connect in mobilen Anwendungen

Die Integration von OpenID Connect in eine mobile Anwendung erfordert die Auswahl der richtigen Bibliothek und die korrekte Konfiguration des Flows. Für Android verwenden Sie den Credential Manager (AndroidX Credentials) oder die AppAuth-Bibliothek. Für iOS verwenden Sie das AuthenticationServices-Framework mit ASWebAuthenticationSession.

Kotlin-Codebeispiel (Android)

Nachfolgend finden Sie ein Beispiel zum Starten des Authorization Code Flows mit der AppAuth-Android-Bibliothek. Die Anwendung erstellt eine Autorisierungsanfrage, öffnet einen Browser für die Benutzeranmeldung und verarbeitet den Callback mit den Tokens.

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

Swift-Codebeispiel (iOS)

Apples ASWebAuthenticationSession bietet einen integrierten Browser für den OIDC-Flow mit SSO-Unterstützung über den iCloud Keychain. Die Sitzung wird mit der Autorisierungs-URL gestartet, und der Callback wird über einen Completion Handler verarbeitet.

Bei der Auswahl einer Bibliothek für OpenID Connect berücksichtigen Sie die integrierte PKCE-Unterstützung: AppAuth-Android und AppAuth-iOS unterstützen PKCE standardmäßig. Firebase Authentication verwendet OIDC intern für Google Sign-In, Sign in with Apple und Microsoft — der Entwickler muss den Flow nicht manuell implementieren. Für Unternehmenssysteme mit einem benutzerdefinierten IdP (z. B. Keycloak oder Okta) bleibt AppAuth die Standardwahl mit vollständiger Kontrolle über Konfiguration und Fehlerbehandlung.

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