OAuth 2.0 erklärt: Zugriff delegieren ohne Passwort

OAuth 2.0 ist ein Standard, mit dem eine Anwendung begrenzten Zugriff auf Ihre Daten bei einem anderen Dienst bekommt, ohne dass sie Ihr Passwort erhält. Am besten stellt man es sich als Hotel-Schlüsselkarte vor: Sie öffnet Zimmer und Fitnessraum für einen festen Zeitraum, das Hotel kann sie jederzeit sperren, aber ein Reisepass ist sie nicht.

Wofür es OAuth 2.0 gibt

Eine Kalender-App möchte Ihren Google-Kalender lesen, ein Druckdienst Fotos aus einem Cloud-Speicher holen. Früher gab man dafür sein Passwort heraus. Die App bekam damit alles, und zurücknehmen ließ sich das nur durch ein neues Passwort. OAuth 2.0 ersetzt das durch Token: kleine, eng gefasste, zeitlich begrenzte Berechtigungen, ausgestellt von dem Dienst, der Ihre Daten hält.

Die Spezifikation ist RFC 6749 (2012), die Nutzung von Bearer-Token steht in RFC 6750. OAuth ist ein Rahmenwerk und kein einzelnes Protokoll; in der Praxis wählt man aus mehreren „Grant Types“.

Die Rollen

Rolle	Wer das ist	Beispiel
Resource Owner	Besitzer der Daten	Sie
Client	Die App, die Zugriff will	Eine Kalender-Planer-App
Authorization Server	Authentifiziert Sie und stellt Token aus	Login- und Einwilligungsdienst des Anbieters
Resource Server	Die Schnittstelle mit den Daten	Die Kalender-API

So läuft der Authorization-Code-Flow ab

Dies ist der empfohlene Ablauf für fast alles, bei dem ein Mensch beteiligt ist.

1. Der Client leitet Sie zum Authorization Server und nennt, was er möchte, zum Beispiel scope=calendar.read.
2. Der Server authentifiziert Sie und zeigt eine Einwilligung: „Planer möchte Ihren Kalender lesen“.
3. Stimmen Sie zu, leitet der Server Sie mit einem einmaligen Autorisierungscode zurück zum Client.
4. Der Client ruft den Token-Endpunkt auf, weist sich aus und tauscht den Code gegen ein Access-Token und oft ein Refresh-Token.
5. Der Client ruft die API mit dem Access-Token auf. Die API prüft das Token und liefert nur, was der Scope erlaubt.
6. Läuft das Access-Token ab, holt der Client mit dem Refresh-Token ein neues, ohne Sie zu stören.

Eine Token-Antwort ist kurz:

{
  "access_token": "SlAV32hkKG",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "8xLOxBtZp8",
  "scope": "calendar.read"
}

Für andere Lagen gibt es weitere Grant Types: Client Credentials für Server-zu-Server-Aufrufe ohne Nutzer und den Device-Code-Grant (RFC 8628) für Smart-TVs und Konsolen. Implicit Grant und Resource-Owner-Password-Grant werden nicht mehr empfohlen.

Beispiele aus dem Alltag

• „Dieser App Zugriff auf Ihr Google Drive erlauben“-Bildschirme.
• Eine Banking-App, die Ihre Kontodaten nach Freigabe bei Ihrer Bank abruft (Open-Banking-Schnittstellen in der EU beruhen häufig auf OAuth-2.0-Profilen).
• Ein Smart-TV, der einen Code anzeigt, den Sie am Handy eingeben, um das Streaming-Konto zu verknüpfen.
• Ein Entwicklerwerkzeug, das in Ihrem Namen auf einer Code-Plattform veröffentlicht.

Sicherheitsaspekte

• PKCE (RFC 7636) bindet den Code an den Client, der ihn angefordert hat, sodass ein gestohlener Code nutzlos ist. Es wird für alle Clients empfohlen.
• Exakte Redirect-URIs. Wer die vollständige Rücksprungadresse registriert und exakt abgleicht, verhindert Code- und Token-Diebstahl.
• Kurzlebige Access-Token. Ein Bearer-Token funktioniert für jeden, der es besitzt. Deshalb kurze Laufzeiten und enge Scopes. Sender-constrained Token wie DPoP (RFC 9449) erschweren die Nutzung gestohlener Token.
• Consent-Phishing. Angreifer registrieren harmlos wirkende Apps und bringen Nutzer dazu, Zugriff zu erteilen. Lesen Sie, was eine Einwilligung verlangt, und prüfen Sie verbundene Apps gelegentlich.
• Access-Token sind kein Identitätsnachweis. Ein Token zeigt, dass jemand Zugriff erteilt hat, nicht, wer sich angemeldet hat. Dieser Fehler steckt hinter vielen realen Angriffen und ist der Grund für OpenID Connect.
• Aktuelle Empfehlung. RFC 9700, die OAuth 2.0 Security Best Current Practice vom Januar 2025, fasst die Erfahrungen seit 2012 zusammen.

Scopes und Einwilligung in der Praxis

Ein Scope ist die Bezeichnung einer Berechtigung, etwa calendar.read oder photos.upload. Die App fordert Scopes an, der Authorization Server zeigt sie auf der Einwilligungsseite in verständlicher Sprache, und das Access-Token trägt nur das, was Sie bestätigt haben. Gute Anbieter trennen Lese- und Schreibrechte und lassen Sie Freigaben später prüfen und zurückziehen. Behandeln Sie eine Einwilligungsseite wie eine Installationsabfrage: Verlangt eine Taschenlampen-App Zugriff auf Ihre Mails, lehnen Sie ab. Als Entwickler fordern Sie den kleinsten funktionierenden Scope an und mehr erst, wenn eine Funktion es braucht.

Auch als Nutzer können Sie etwas tun: Prüfen Sie von Zeit zu Zeit in den Sicherheitseinstellungen Ihrer wichtigen Konten die Liste verbundener Apps, und entfernen Sie alles, was Sie nicht mehr nutzen. Das ist eine der wirksamsten Aufräumaktionen gegen unbemerkte Zugriffe.

Status und Versionen

OAuth 2.0 ist weiterhin ein veröffentlichter IETF-Standard. OAuth 2.1 will die Sicherheitslehren in einem Dokument bündeln, das RFC 6749 und RFC 6750 ersetzen würde. Laut IETF Datatracker ist es noch ein Internet-Draft (Revision 16 vom 3. September 2026), mit einem Meilenstein der Arbeitsgruppe, es im Dezember 2026 an die IESG zu geben. Bis zur Veröffentlichung als RFC beschreibt „OAuth 2.1“ ein Profil, dem viele Bibliotheken bereits folgen, aber keinen fertigen Standard. Zu den Erweiterungen zählen PAR (RFC 9126) und die Hinweise für native Apps in RFC 8252.

Verhältnis zu anderen Standards

OAuth 2.0 ist die Basisschicht. OpenID Connect ergänzt das ID-Token für die Anmeldung, den Vergleich zeigt OpenID vs. OAuth. SAML löst ein verwandtes Föderationsproblem mit einem anderen, XML-basierten Ansatz, und die Nachweisprotokolle der EU-Wallet bauen ebenfalls auf OAuth auf.

Rolle in der EUDI-Wallet

Die EUDI-Wallet nutzt OAuth-Mechanik an zwei Stellen. Wenn sie einen Ausweis oder Nachweis erhält, verwendet OpenID4VCI OAuth-2.0-Abläufe (Authorization Code oder Pre-Authorized Code), um die Ausstellung zu autorisieren. Wenn sie einen Nachweis vorzeigt, übernimmt OpenID4VP das OAuth-typische Anfrage-Antwort-Muster. Für Nutzer ist davon nichts sichtbar, es erklärt aber, warum Entwickler, die OAuth kennen, die Wallet-Protokolle vertraut finden.