OIDC

OIDC (OpenID Connect) ist ein offenes Authentifizierungsprotokoll, das auf OAuth 2.0 aufbaut. Waehrend OAuth 2.0 die Frage beantwortet "Was darf eine Anwendung tun?", klaert OIDC die Frage "Wer ist der Benutzer?". Es handelt sich also um eine Identitaetsschicht, die OAuth 2.0 um die Faehigkeit erweitert, Benutzer zu identifizieren und deren Profilinformationen sicher zu uebertragen.

Wenn du dich auf einer Webseite mit "Mit Google anmelden" oder "Mit Microsoft anmelden" einloggst, nutzt du hoechstwahrscheinlich OpenID Connect. Die Webseite erhaelt dabei nicht dein Passwort, sondern nur einen Nachweis deiner Identitaet - ausgestellt vom Identity Provider (Google, Microsoft, etc.). Dieses Verfahren ist sicherer als klassische Passwoerter und ermoeglicht Single Sign-On (SSO) ueber verschiedene Anwendungen hinweg.

Geschichte und Entwicklung

OpenID Connect wurde 2014 von der OpenID Foundation veroeffentlicht. 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 unterstuetzen praktisch alle grossen Identity Provider wie Google, Microsoft, Apple, Facebook und Amazon OpenID Connect. Auch Enterprise-Loesungen wie Okta, Auth0 und Keycloak setzen auf OIDC als primaeres Authentifizierungsprotokoll.

OAuth 2.0 vs. OpenID Connect

Der Unterschied zwischen OAuth 2.0 und OpenID Connect ist fundamental und wird haeufig missverstanden. OAuth 2.0 ist ein Autorisierungsframework, das regelt, welche Berechtigungen eine Anwendung erhaelt. OpenID Connect hingegen ist ein Authentifizierungsprotokoll, das die Identitaet des Benutzers verifiziert.

In der Praxis werden beide Protokolle oft gemeinsam eingesetzt: OIDC authentifiziert den Benutzer und liefert ein ID Token mit Identitaetsinformationen, waehrend OAuth 2.0 der Anwendung Zugriff auf weitere Ressourcen (APIs) gewaehrt. 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 fuehrt mehrere wichtige Konzepte ein, die ueber OAuth 2.0 hinausgehen. Das Verstaendnis dieser Bausteine ist entscheidend fuer die Arbeit mit OIDC.

ID Token

Das ID Token ist das Herzsctueck von OpenID Connect. Es handelt sich um ein JSON Web Token (JWT), das Informationen ueber den authentifizierten Benutzer enthaelt. Im Gegensatz zum Access Token, das fuer API-Zugriffe verwendet wird, dient das ID Token ausschliesslich der Identitaetspruefung.

{
  "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 oeffentlichen Schluessel des Identity Providers prueft. Dadurch wird sichergestellt, dass das Token authentisch ist und nicht manipuliert wurde.

Claims

Claims sind Aussagen ueber den Benutzer, die im ID Token enthalten sind. OIDC definiert standardisierte Claims, die von allen Providern unterstuetzt 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, fuer die das Token bestimmt ist
• exp (Expiration): Ablaufzeitpunkt des Tokens als Unix-Timestamp
• iat (Issued At): Zeitpunkt der Token-Ausstellung
• name: Vollstaendiger 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 verfuegbaren Claims:

• openid: Erforderlich fuer 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 geschuetzte API des Identity Providers, die zusaetzliche Benutzerinformationen liefert. Waehrend das ID Token nur die grundlegenden Claims enthaelt, kann die Anwendung ueber 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 moechte
• Relying Party (RP): Die Anwendung, die die Authentifizierung anfordert - entspricht dem OAuth-Client
• OpenID Provider (OP): Der Identity Provider, der die Authentifizierung durchfuehrt und Tokens ausstellt (z.B. Google, Microsoft, Keycloak)

OIDC Flows

OpenID Connect definiert drei Authentifizierungsflows, die fuer unterschiedliche Anwendungstypen optimiert sind. Die Wahl des richtigen Flows haengt von der Art der Anwendung und den Sicherheitsanforderungen ab.

Authorization Code Flow

Der Authorization Code Flow ist der sicherste und am haeufigsten verwendete Flow. Er eignet sich besonders fuer serverseitige Webanwendungen, die ein Client Secret sicher speichern koennen. 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 zurueck 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 grosse Vorteil: Das ID Token wird nie ueber den Browser uebertragen, sondern direkt vom Backend abgerufen. Das minimiert das Risiko von Token-Diebstahl. Fuer 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 zurueck, ohne den Umweg ueber einen Autorisierungscode. Er wurde urspruenglich fuer browserbasierte Anwendungen entwickelt, gilt heute jedoch als veraltet und unsicher. Die OpenID Foundation empfiehlt stattdessen den Authorization Code Flow mit PKCE - auch fuer SPAs.

Hybrid Flow

Der Hybrid Flow kombiniert Elemente beider Ansaetze: Das ID Token wird direkt zurueckgeliefert, waehrend der Access Token ueber einen Autorisierungscode abgerufen wird. Dieser Flow ist fuer spezielle Anwendungsfaelle gedacht, bei denen die Anwendung das ID Token sofort benoetigt, aber den Access Token sicher ueber das Backend beziehen moechte.

Discovery und Konfiguration

Ein grosser Vorteil von OIDC ist die automatische Konfiguration ueber den Discovery Endpoint. Jeder OpenID Provider stellt unter der URL /.well-known/openid-configuration ein JSON-Dokument bereit, das alle Endpunkte, unterstuetzten 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 koennen 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 Prioritaet entwickelt. Dennoch erfordert eine sichere Implementierung die Beachtung wichtiger Best Practices:

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

Praktische Einsatzgebiete

OpenID Connect ist heute der De-facto-Standard fuer Authentifizierung im Web und in Enterprise-Umgebungen. Die wichtigsten Anwendungsfaelle sind:

• Social Login: "Mit Google anmelden", "Mit Apple anmelden", "Mit Microsoft anmelden"
• Enterprise SSO: Einmalige Anmeldung fuer alle Unternehmensanwendungen
• API-Authentifizierung: Sichere Authentifizierung fuer REST-APIs und Microservices
• Mobile Apps: Native Apps nutzen OIDC mit PKCE fuer sichere Authentifizierung
• Single Page Applications: React, Angular und Vue-Apps mit Identity Providern verbinden
• Foederierte Identitaet: Identitaeten ueber Organisationsgrenzen hinweg nutzen

OIDC in der Praxis

Fuer Fachinformatiker im Bereich Anwendungsentwicklung ist das Verstaendnis von OpenID Connect heute unabdingbar. Moderne Webanwendungen setzen fast ausnahmslos auf OIDC fuer 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 fuer Systemintegration begegnen OIDC regelmaessig - etwa beim Einrichten von Identity Providern wie Microsoft Entra ID (frueher Azure AD), Keycloak oder beim Anbinden von Cloud-Diensten an die Unternehmensinfrastruktur. Die Konfiguration von OIDC-basierten SSO-Loesungen gehoert zum Handwerkszeug moderner IT-Fachkraefte.

Quellen und weiterfuehrende Links

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