OpenID vs. OAuth: Authentifizierung vs. Autorisierung

OAuth und OpenID Connect werden oft in einem Atemzug genannt, deshalb halten viele sie für Alternativen. Das sind sie nicht. OAuth 2.0 regelt die Autorisierung: was eine App tun darf. OpenID Connect regelt die Authentifizierung: wer der Nutzer ist. OpenID Connect ist eine dünne Schicht auf OAuth 2.0.

Die kurze Analogie

An der Hotelrezeption erhalten Sie eine Schlüsselkarte. Sie öffnet Ihr Zimmer und den Spa für drei Nächte. Das ist OAuth: Zugang zu bestimmten Dingen, zeitlich begrenzt, ohne dass bei jedem Auflegen etwas über Sie bewiesen wird.

Beim Einchecken hat die Rezeption außerdem Ihren Ausweis angesehen und Ihren Namen in die Buchung eingetragen. Das ist OpenID Connect: Eine Stelle mit Autorität hat festgestellt, wer Sie sind, und das Ergebnis dem System übergeben.

Würde eine Bar die Schlüsselkarte als Beweis akzeptieren, dass Sie der eingetragene Gast sind, könnte sich jeder, der sie findet, als Sie ausgeben. Genau diesen Fehler machen Entwickler, wenn sie ein OAuth-Access-Token als Login behandeln.

Vergleich nebeneinander

	OAuth 2.0	OpenID Connect	OpenID 2.0 (ausgemustert)
Kernfrage	Worauf darf die App zugreifen?	Wer hat sich angemeldet?	Wer hat sich angemeldet?
Ergebnis	Access-Token (opak oder JWT)	ID-Token (JWT) plus Access-Token	Signierte Aussage in URL-Parametern
Basiert auf	Eigenem Rahmenwerk (RFC 6749)	OAuth 2.0	Eigenem Protokoll, ohne OAuth
Typischer Einsatz	API-Zugriff, Open Banking, App-Anbindungen	Anmeldung, Single Sign-on	Web-Logins der 2000er
Beschreibt den Nutzer?	Nein	Ja: Standard-Claims wie sub, email	Ja, über Erweiterungen
Status	Veröffentlichter Standard, OAuth 2.1 im Entwurf	Aktiv, von der OpenID Foundation gepflegt	Seit 2014 abgelöst

Wie beide in einer Anfrage zusammenspielen

Ein „Anmelden mit …“-Knopf, der zusätzlich Kalenderzugriff möchte, sendet eine Anfrage mit mehreren Scopes:

scope=openid email calendar.read

openid schaltet OpenID Connect ein und veranlasst den Anbieter, ein ID-Token zu liefern. email fordert eine Standard-Identitätsangabe an. calendar.read ist eine gewöhnliche OAuth-Berechtigung. Die App erhält dann zwei Dinge:

1. Ein ID-Token, um zu erfahren, wer sich angemeldet hat.
2. Ein Access-Token, um die Kalender-API aufzurufen.

Schritt für Schritt:

1. Der Nutzer klickt in der App auf „Anmelden“.
2. Die App leitet mit den genannten Scopes zum Anbieter weiter.
3. Der Anbieter authentifiziert den Nutzer und holt die Einwilligung ein.
4. Die App erhält einen Code, tauscht ihn ein und bekommt beide Token.
5. Die App validiert das ID-Token, um eine Login-Sitzung zu erzeugen, und nutzt das Access-Token nur für API-Aufrufe.

Die Mechanik beschreiben OAuth 2.0 erklärt und OpenID Connect erklärt.

Beispiele aus dem Alltag

• Nur OAuth: Ein Fotodienst darf ein Album lesen. Wer Sie sind, muss er nicht wissen.
• OpenID Connect: Eine Nachrichtenseite lässt Sie kommentieren, nachdem Sie sich mit einem Social-Konto angemeldet haben, und liest nur Name und E-Mail.
• Beides: Ein Projekt-Tool meldet Sie mit Ihrem Firmenkonto an und liest dann Ihren Kalender, um Termine zu planen.

Sicherheitsaspekte

• Nie ein Access-Token als Login-Beweis akzeptieren. Ein Angreifer kann ein Access-Token für eine App erhalten und bei einer anderen vorlegen. Ein ID-Token enthält einen aud-Claim für die gemeinte App und eine nonce, was das verhindert.
• ID-Token validieren, nicht nur entgegennehmen. Signatur, Aussteller, Zielgruppe, Ablauf und Nonce prüfen.
• Token in ihrer Spur halten. Access-Token gehen nur an APIs; ID-Token bleiben in der eigenen App- und Sitzungslogik.
• So wenig wie nötig anfordern. Nur die benötigten Scopes verlangen. Breite Scopes erleichtern Consent-Phishing und kosten Vertrauen.
• Authentifizierung ist keine Identitätsprüfung. Auch ein korrekter OpenID-Connect-Login sagt nur, dass jemand ein Konto kontrolliert. Den Unterschied erklärt Identität vs. Authentifizierung.

Verbreitete Missverständnisse

• „OAuth ist für den Login.“ Es wurde für delegierten Zugriff entworfen. Der Login ergab sich aus der Art, wie es genutzt wurde, und OpenID Connect hat ihn sicher formalisiert.
• „OpenID Connect ersetzt OAuth.“ Nein. Es braucht OAuth als Unterbau und ergänzt die Identität obendrauf.
• „Mit einem ID-Token kann ich APIs aufrufen.“ Das geht nicht und soll es nicht. Das ID-Token gehört der App, die es angefordert hat, das Access-Token der API.
• „Beide beweisen, wer ich rechtlich bin.“ Keines von beiden. Sie zeigen die Kontrolle über ein Konto, nicht eine geprüfte rechtliche Identität.
• „Das ist nur für Entwickler.“ Als Nutzer begegnen Sie beidem täglich, bei jedem „Weiter mit …“ und jeder Berechtigungsabfrage einer App. Wer die Begriffe kennt, liest solche Abfragen aufmerksamer.

Eine einfache Faustregel hilft im Alltag: Geht es darum, dass eine App etwas für Sie tun darf, ist es OAuth. Geht es darum, dass ein Dienst erfahren soll, wer Sie sind, ist es OpenID Connect.

Status und Versionen

OAuth 2.0 ist RFC 6749, in der Praxis ergänzt durch die Sicherheitsempfehlungen in RFC 9700; OAuth 2.1 war im Oktober 2026 noch ein Internet-Draft. OpenID Connect Core 1.0 stammt von 2014 und liegt unter openid.net/specs. OpenID 2.0 wird nicht mehr weiterentwickelt; den Wechsel beschreibt Von OpenID zu OpenID Connect, das Protokoll selbst OpenID 2.0.

Wo die EU-Wallet einzuordnen ist

Die EUDI-Wallet geht einen Schritt weiter als beide. Es geht nicht um den Login in ein Konto oder um API-Zugriff, sondern darum, geprüfte Merkmale wie einen Namen oder eine Altersbestätigung mitzuführen und nur das Nötige zu zeigen. Die Protokolle dafür, OpenID4VCI und OpenID4VP, übernehmen Ideen aus OAuth und OpenID Connect wie Autorisierungscodes, signierte JWTs und Weiterleitungsabläufe. Deshalb lohnt es sich, die Grundlagen aus diesem Artikel zu kennen, bevor man sich mit der Wallet beschäftigt.