OIDC

OIDC (OpenID Connect) ist ein offenes Authentifizierungsprotokoll, das auf OAuth 2.0 aufbaut. Während OAuth 2.0 die Frage beantwortet “Was darf eine Anwendung tun?”, klärt OIDC die Frage “Wer ist der Benutzer?”. Es handelt sich also um eine Identitätsschicht, die OAuth 2.0 um die Fähigkeit erweitert, Benutzer zu identifizieren und deren Profilinformationen sicher zu übertragen.

Wenn du dich auf einer Webseite mit “Mit Google anmelden” oder “Mit Microsoft anmelden” einloggst, nutzt du höchstwahrscheinlich OpenID Connect. Die Webseite erhält dabei nicht dein Passwort, sondern nur einen Nachweis deiner Identität, ausgestellt vom Identity Provider (Google, Microsoft, etc.). Dieses Verfahren ist sicherer als klassische Passwörter und ermöglicht Single Sign-On (SSO) über verschiedene Anwendungen hinweg.

Geschichte und Entwicklung

OpenID Connect wurde 2014 von der OpenID Foundation veröffentlicht. Es ist der Nachfolger von OpenID 2.0, das zwar weit verbreitet war, aber als zu komplex und schwer zu implementieren galt. Die Entwickler entschieden sich, auf dem bereits erfolgreichen OAuth 2.0 Framework aufzubauen, anstatt ein komplett neues Protokoll zu entwickeln.

Diese Entscheidung erwies sich als klug: Da viele Entwickler bereits mit OAuth 2.0 vertraut waren, konnte OIDC schnell adoptiert werden. Heute unterstützen praktisch alle großen Identity Provider wie Google, Microsoft, Apple, Facebook und Amazon OpenID Connect. Auch Enterprise-Lösungen wie Okta, Auth0 und Keycloak setzen auf OIDC als primäres Authentifizierungsprotokoll.

OAuth 2.0 vs. OpenID Connect

Der Unterschied zwischen OAuth 2.0 und OpenID Connect ist fundamental und wird häufig missverstanden. OAuth 2.0 ist ein Autorisierungsframework, das regelt, welche Berechtigungen eine Anwendung erhält. OpenID Connect hingegen ist ein Authentifizierungsprotokoll, das die Identität des Benutzers verifiziert.

In der Praxis werden beide Protokolle oft gemeinsam eingesetzt: OIDC authentifiziert den Benutzer und liefert ein ID Token mit Identitätsinformationen, während OAuth 2.0 der Anwendung Zugriff auf weitere Ressourcen (APIs) gewährt. Das ist der Grund, warum du bei “Mit Google anmelden” oft gefragt wirst, ob die App auch auf deine E-Mails oder deinen Kalender zugreifen darf.

Kernkonzepte von OpenID Connect

OpenID Connect führt mehrere wichtige Konzepte ein, die über OAuth 2.0 hinausgehen. Das Verständnis dieser Bausteine ist entscheidend für die Arbeit mit OIDC.

ID Token

Das ID Token ist das Herzstück von OpenID Connect. Es handelt sich um ein JSON Web Token (JWT), das Informationen über den authentifizierten Benutzer enthält. Im Gegensatz zum Access Token, das für API-Zugriffe verwendet wird, dient das ID Token ausschließlich der Identitätsprüfung.

{
  "iss": "https://accounts.google.com",
  "sub": "110169484474386276334",
  "aud": "1234987819200.apps.googleusercontent.com",
  "iat": 1353601026,
  "exp": 1353604926,
  "email": "max.mustermann@gmail.com",
  "name": "Max Mustermann",
  "picture": "https://lh3.googleusercontent.com/a/photo.jpg"
}

Die Client-Anwendung kann das ID Token verifizieren, indem sie die Signatur mit dem öffentlichen Schlüssel des Identity Providers prüft. Dadurch wird sichergestellt, dass das Token authentisch ist und nicht manipuliert wurde.

Claims

Claims sind Aussagen über den Benutzer, die im ID Token enthalten sind. OIDC definiert standardisierte Claims, die von allen Providern unterstützt werden sollten:

• sub (Subject): Eindeutige Kennung des Benutzers beim Provider
• iss (Issuer): URL des Identity Providers, der das Token ausgestellt hat
• aud (Audience): Client-ID der Anwendung, für die das Token bestimmt ist
• exp (Expiration): Ablaufzeitpunkt des Tokens als Unix-Timestamp
• iat (Issued At): Zeitpunkt der Token-Ausstellung
• name: Vollständiger Name des Benutzers
• email: E-Mail-Adresse
• picture: URL zum Profilbild

Scopes

Scopes definieren, welche Informationen die Anwendung vom Identity Provider anfordert. Der Scope openid ist verpflichtend und signalisiert, dass es sich um eine OIDC-Anfrage handelt. Weitere Standard-Scopes erweitern die verfügbaren Claims:

• openid: Erforderlich für OIDC, liefert das ID Token
• profile: Name, Profilbild, Geburtstag, etc.
• email: E-Mail-Adresse und Verifikationsstatus
• address: Postadresse des Benutzers
• phone: Telefonnummer

UserInfo Endpoint

Der UserInfo Endpoint ist eine geschützte API des Identity Providers, die zusätzliche Benutzerinformationen liefert. Während das ID Token nur die grundlegenden Claims enthält, kann die Anwendung über diesen Endpoint weitere Details abrufen, vorausgesetzt, der Benutzer hat die entsprechenden Scopes freigegeben.

Die drei Akteure

An einem OIDC-Authentifizierungsvorgang sind drei Parteien beteiligt. Die Terminologie unterscheidet sich leicht von OAuth 2.0:

• End-User: Der Benutzer, der sich authentifizieren möchte
• Relying Party (RP): Die Anwendung, die die Authentifizierung anfordert, entspricht dem OAuth-Client
• OpenID Provider (OP): Der Identity Provider, der die Authentifizierung durchführt und Tokens ausstellt (z.B. Google, Microsoft, Keycloak)

OIDC Flows

OpenID Connect definiert drei Authentifizierungsflows, die für unterschiedliche Anwendungstypen optimiert sind. Die Wahl des richtigen Flows hängt von der Art der Anwendung und den Sicherheitsanforderungen ab.

Authorization Code Flow

Der Authorization Code Flow ist der sicherste und am häufigsten verwendete Flow. Er eignet sich besonders für serverseitige Webanwendungen, die ein Client Secret sicher speichern können. Der Ablauf funktioniert in mehreren Schritten:

1. Benutzer klickt “Mit Google anmelden”
2. Anwendung leitet zum OpenID Provider weiter (mit Scope openid)
3. Benutzer meldet sich beim Provider an und erteilt Berechtigung
4. Provider leitet mit Autorisierungscode zurück zur Anwendung
5. Anwendung tauscht Code + Client Secret gegen ID Token und Access Token
6. Anwendung verifiziert das ID Token und liest Benutzerinfos aus

Der große Vorteil: Das ID Token wird nie über den Browser übertragen, sondern direkt vom Backend abgerufen. Das minimiert das Risiko von Token-Diebstahl. Für Single Page Applications (SPAs) und Mobile Apps sollte dieser Flow mit PKCE (Proof Key for Code Exchange) kombiniert werden.

Implicit Flow (veraltet)

Der Implicit Flow liefert das ID Token direkt im URL-Fragment zurück, ohne den Umweg über einen Autorisierungscode. Er wurde ursprünglich für browserbasierte Anwendungen entwickelt, gilt heute jedoch als veraltet und unsicher. Die OpenID Foundation empfiehlt stattdessen den Authorization Code Flow mit PKCE, auch für SPAs.

Hybrid Flow

Der Hybrid Flow kombiniert Elemente beider Ansätze: Das ID Token wird direkt zurückgeliefert, während der Access Token über einen Autorisierungscode abgerufen wird. Dieser Flow ist für spezielle Anwendungsfälle gedacht, bei denen die Anwendung das ID Token sofort benötigt, aber den Access Token sicher über das Backend beziehen möchte.

Discovery und Konfiguration

Ein großer Vorteil von OIDC ist die automatische Konfiguration über den Discovery Endpoint. Jeder OpenID Provider stellt unter der URL /.well-known/openid-configuration ein JSON-Dokument bereit, das alle Endpunkte, unterstützten Flows und Signaturalgorithmen beschreibt.

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "scopes_supported": ["openid", "email", "profile"],
  "response_types_supported": ["code", "token", "id_token"]
}

Dadurch können OIDC-Bibliotheken die Konfiguration automatisch abrufen, ohne dass du Endpunkte manuell eintragen musst. Du gibst nur die Issuer-URL an, und die Bibliothek erledigt den Rest.

Sicherheitsaspekte

OpenID Connect wurde mit Sicherheit als oberster Priorität entwickelt. Dennoch erfordert eine sichere Implementierung die Beachtung wichtiger Best Practices:

• ID Token immer verifizieren: Prüfe Signatur, Issuer, Audience und Ablaufzeit
• PKCE verwenden: Auch bei vertraulichen Clients erhöht PKCE die Sicherheit
• State-Parameter nutzen: Schützt vor Cross-Site Request Forgery (CSRF)
• Nonce validieren: Verhindert Replay-Angriffe bei ID Tokens
• HTTPS erzwingen: Alle OIDC-Kommunikation muss TLS-verschlüsselt erfolgen
• Tokens sicher speichern: ID Tokens niemals im Local Storage, bevorzuge HTTP-Only Cookies

Praktische Einsatzgebiete

OpenID Connect ist heute der De-facto-Standard für Authentifizierung im Web und in Enterprise-Umgebungen. Die wichtigsten Anwendungsfälle sind:

• Social Login: “Mit Google anmelden”, “Mit Apple anmelden”, “Mit Microsoft anmelden”
• Enterprise SSO: Einmalige Anmeldung für alle Unternehmensanwendungen
• API-Authentifizierung: Sichere Authentifizierung für REST-APIs und Microservices
• Mobile Apps: Native Apps nutzen OIDC mit PKCE für sichere Authentifizierung
• Single Page Applications: React, Angular und Vue-Apps mit Identity Providern verbinden
• Föderierte Identität: Identitäten über Organisationsgrenzen hinweg nutzen

OIDC in der Praxis

Für Fachinformatiker im Bereich Anwendungsentwicklung ist das Verständnis von OpenID Connect heute unabdingbar. Moderne Webanwendungen setzen fast ausnahmslos auf OIDC für Authentifizierung und Single Sign-On. Beliebte Frameworks wie Spring Security, Passport.js oder NextAuth.js bieten fertige OIDC-Integrationen, die dir die Implementierung erleichtern.

Auch Fachinformatiker für Systemintegration begegnen OIDC regelmäßig, etwa beim Einrichten von Identity Providern wie Microsoft Entra ID (früher Azure AD), Keycloak oder beim Anbinden von Cloud-Diensten an die Unternehmensinfrastruktur. Die Konfiguration von OIDC-basierten SSO-Lösungen gehört zum Handwerkszeug moderner IT-Fachkräfte.

Quellen und weiterführende Links

• OpenID Connect Core 1.0 Spezifikation - Offizielle Spezifikation
• OpenID Foundation - How Connect Works - Einführung der OpenID Foundation
• Auth0 - OpenID Connect Protocol - Praxisorientierte Dokumentation
• Google Identity - OpenID Connect - Google Entwicklerdokumentation
• Microsoft Entra ID - OIDC - Microsoft Dokumentation