OpenID Connect erklärt: Login auf Basis von OAuth 2.0

OpenID Connect (OIDC) ist ein Standard, mit dem eine Anwendung herausfindet, wer ein Nutzer ist, indem sie einen Anbieter fragt, dem der Nutzer bereits vertraut: ein Firmenverzeichnis, Google oder ein staatliches Anmeldeportal. Der Nutzer meldet sich beim Anbieter an, und der Anbieter teilt der Anwendung das Ergebnis in einer signierten Nachricht mit. Das Passwort sieht die Anwendung nie.

Wofür es OpenID Connect gibt

Vor OIDC führte jede Website ihre eigene Liste mit Benutzernamen und Passwörtern. Das bedeutete Dutzende Passwörter, Dutzende Datenbanken, die abfließen können, und Dutzende Wiederherstellungsprozesse. OIDC verlegt die Anmeldung an einen Ort, den OpenID Provider, und lässt viele Anwendungen, die Relying Parties, darauf bauen. Dieselbe Idee trägt das Single Sign-on im Büro und die Social-Login-Schaltflächen auf Verbraucherseiten.

OIDC ist bewusst schlank. Es ergänzt OAuth 2.0 um genau eine Sache: eine einheitliche Aussage „dieser Nutzer wurde authentifiziert, hier ist, wer er ist“. OAuth 2.0 allein regelt nur den Zugriff auf Ressourcen und sagt nichts über Identität. Den Unterschied behandelt OpenID vs. OAuth.

Herkunft

Das erste OpenID kam 2005, OpenID Authentication 2.0 wurde im Dezember 2007 verabschiedet. Es war elegant, aber für Nutzer und Entwickler sperrig, und große Plattformen gingen mit eigenen Social-Logins ihren eigenen Weg. Im Februar 2014 veröffentlichte die OpenID Foundation OpenID Connect 1.0, aufgebaut auf OAuth 2.0 und JSON Web Tokens, als Nachfolger. Die Geschichte erzählt Von OpenID zu OpenID Connect, das ursprüngliche Protokoll beschreibt OpenID 2.0.

Die Rollen

Rolle	Aufgabe	Alltagsbeispiel
Endnutzer	Person, die sich anmelden möchte	Sie
Relying Party (RP)	Die App, die wissen will, wer Sie sind	Nachrichtenseite, Firmen-Intranet
OpenID Provider (OP)	Authentifiziert Sie und stellt Token aus	Login des Arbeitgebers, Google, ein staatliches eID-Portal

Mehr zur App-Seite finden Sie unter Was ist eine Relying Party?.

So läuft eine Anmeldung ab

Empfohlen ist der Authorization-Code-Flow mit PKCE.

1. Sie klicken in der App auf „Anmelden“. Die App leitet Ihren Browser zum Anbieter weiter und fordert den Scope openid an, meist mit profile oder email.
2. Der Anbieter authentifiziert Sie mit dem Verfahren, das er anbietet: Passwort, Passkey, Hardware-Schlüssel oder mobile eID.
3. Der Anbieter fragt, ob Sie die angeforderten Daten mit dieser App teilen möchten.
4. Der Anbieter leitet Sie mit einem kurzlebigen Autorisierungscode zurück zur App.
5. Die App tauscht den Code serverseitig am Token-Endpunkt des Anbieters gegen ein ID-Token und ein Access-Token.
6. Die App prüft das ID-Token und legt eine Sitzung für Sie an. Braucht sie mehr Daten, ruft sie den UserInfo-Endpunkt auf.

Eine vereinfachte Anfrage sieht so aus:

GET /authorize?response_type=code
  &client_id=shop-app
  &redirect_uri=https://shop.example/callback
  &scope=openid%20email
  &state=af0ifjsldkj
  &nonce=n-0S6_WzA2Mj
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

Das ID-Token

Das ID-Token ist ein vom Anbieter signiertes JSON Web Token (JWT, RFC 7519). Die Nutzdaten enthalten einige Standardangaben („Claims“):

{
  "iss": "https://login.example.org",
  "sub": "248289761001",
  "aud": "shop-app",
  "exp": 1790000000,
  "iat": 1789996400,
  "nonce": "n-0S6_WzA2Mj"
}

iss nennt den Anbieter, sub ist eine beständige Kennung des Nutzers bei diesem Anbieter, aud die App, für die das Token bestimmt ist, und nonce bindet es an die ursprüngliche Anfrage. Die App muss Signatur, Aussteller, Zielgruppe und Ablaufzeit prüfen, bevor sie dem Token vertraut.

Beispiele aus dem Alltag

• Ein Hochschul-Login, der für Bibliothek, Lernplattform und Mail gilt.
• Ein Unternehmen, bei dem Beschäftigte nach einer Anmeldung Dutzende Cloud-Dienste öffnen.
• Ein Shop mit „Weiter mit Google“ oder „Mit Apple anmelden“ (siehe Anmelden mit Google oder Apple).
• Ein Behörden- oder Städteportal, das eine staatliche eID annimmt, indem es selbst als OpenID Provider auftritt.

Sicherheitsaspekte

• Code-Flow mit PKCE nutzen. Der alte Implicit Flow, der Token in der Browser-Adresse zurückgab, wird in aktuellen Sicherheitsempfehlungen wie RFC 9700 nicht mehr empfohlen.
• state und nonce prüfen. Sie schützen vor Cross-Site-Request-Forgery und Token-Wiederverwendung.
• Redirect-URI exakt abgleichen. Großzügiger Abgleich erlaubt Angreifern, Codes abzugreifen.
• Token vollständig validieren. Signatur, iss, aud, exp und nonce zählen alle.
• Datenschutz. Der Anbieter erfährt jede App, bei der Sie sich anmelden. Das ist der Preis zentraler Anmeldung und ein Punkt, an dem sich das Wallet-Design unterscheidet.
• Anbieter als Single Point of Failure. Geht das Konto beim Anbieter verloren oder wird es übernommen, sind alle verbundenen Apps betroffen. Entscheidend ist deshalb eine starke Anmeldung dort, am besten ein Passkey.

Typische Fehler bei der Einrichtung

In der Praxis scheitern OIDC-Anbindungen selten am Protokoll, sondern an Kleinigkeiten: ein Redirect-URI mit abweichendem Schrägstrich, eine ungeprüfte Zielgruppe im Token, abgelaufene Signaturschlüssel des Anbieters oder Uhren, die um Minuten falsch gehen. Wer diese vier Punkte prüft, löst die meisten Probleme schnell.

Status und Versionen

OpenID Connect Core 1.0 wurde im Februar 2014 verabschiedet und seither über Korrekturen („Errata“) gepflegt. Zur Familie gehören außerdem Discovery (ein Dokument unter .well-known/openid-configuration), Dynamic Client Registration und Spezifikationen für das Abmelden. Alle stehen unter openid.net/specs. Die OpenID Foundation betreibt ein Zertifizierungsprogramm für Implementierungen. Ein „OIDC 2.0“ als Ablösung ist nicht angekündigt; das umgebende OAuth-Rahmenwerk wird als OAuth 2.1 zusammengeführt, das im Oktober 2026 noch ein Entwurf ist.

Verhältnis zu anderen Standards

OIDC baut auf OAuth 2.0 auf. In großen Organisationen läuft es oft neben SAML, dem älteren XML-basierten Unternehmensstandard, der ein ähnliches Anmeldeproblem löst. Die neueren Protokolle OpenID4VP und OpenID4VCI für digitale Wallets teilen sich das OAuth- und JWT-Fundament, lösen aber ein anderes Problem: Nachweise ausstellen und vorzeigen statt sich anzumelden.

Rolle in der EUDI-Wallet

Die EUDI-Wallet ist kein OpenID Provider im klassischen Sinn. Ihre Nachweise werden mit OpenID4VCI ausgestellt und mit OpenID4VP vorgezeigt, nicht als ID-Token geliefert. OIDC bleibt drumherum wichtig: Viele Online-Dienste behalten OIDC für ihre eigenen Konten und können eine Wallet-Anmeldung vor einen OIDC-Provider schalten, sodass Nutzer beiden Welten begegnen.