RFC 6749 · · Proposed Standard
Wie Apps Zugriff bekommen, ohne dein Passwort zu bekommen.
Der offizielle Titel lautet "The OAuth 2.0 Authorization Framework." Worüber der RFC wirklich entscheidet: wie eine App in deinem Namen handeln darf, der "Mit Google anmelden"-Ablauf, ohne je dein echtes Passwort zu sehen.
- Status
- Proposed Standard
- Ersetzt
- RFC 5849
Geschrieben von Noel Lang · IT-Trainer
Kurzfassung
RFC 6749 definiert OAuth 2.0, ein Framework für delegierten Zugriff.
Es erlaubt einer Anwendung, einen begrenzten, widerrufbaren Access Token
zu bekommen, um bei einem anderen Dienst in deinem Namen zu handeln, ohne je dein
Passwort zu sehen. Es ist die Maschinerie hinter jedem “Anmelden mit”-Button und den
meisten Drittanbieter-API-Zugriffen. Als Framework definiert es die Abläufe und
überlässt viele Sicherheitsdetails Begleit-Specs wie PKCE und der OAuth
Security BCP.
Welches Problem er löst
Vor OAuth hieß es, eine App im Namen einer anderen handeln zu lassen: gib deinen Benutzernamen und dein Passwort her. Eine Foto-Druckseite soll Bilder aus deinem Cloud-Speicher holen? Du hast dein Speicher-Passwort in den Druckshop getippt. Jetzt hatte er alles, für immer: er konnte deine Fotos lesen, dein Konto löschen, dein Passwort ändern, und die einzige Möglichkeit, das zurückzunehmen, war das Passwort zu ändern und zu hoffen, dass es niemand kopiert hatte.
Passwörter sind Alles-oder-nichts und praktisch nicht widerrufbar. RFC 6749 ersetzt das durch delegierten Zugriff. Du beweist einmal, wer du bist, direkt bei dem Dienst, der dein Passwort schon hat, und dieser Dienst gibt der App einen Token, der genau beschreibt, was sie tun darf und wie lange. OAuth existiert, damit du nie einer App das Passwort für eine andere geben musst. Die App sieht das Passwort nie, und du kannst den Token auf einer Einstellungsseite widerrufen, ohne sonst etwas anzufassen.
Der Tausch ist ehrlich über das, was es ist: OAuth 2.0 ist ein flexibles Framework, kein starres Einzelprotokoll. Sichere Nutzung hängt davon ab, den richtigen Flow zu wählen und späteren Begleitern wie RFC 7636 und den Security-Best-Practice-Dokumenten zu folgen.
Die Analogie mit dem Parkschlüssel
Ein Auto hat oft zwei Arten von Schlüssel. Dein normaler Schlüssel kann alles: fahren, den Kofferraum öffnen, ans Handschuhfach mit Fahrzeugschein und Garagenöffner. Der Parkschlüssel (Valet Key) kann bewusst weniger. Er startet den Motor und öffnet die Tür, aber Kofferraum und Handschuhfach bleiben verschlossen. Du gibst ihn einem Parkwächter, dem du nicht ganz vertraust, gerade weil er nicht viel kann.
Ein OAuth-Access-Token ist ein Parkschlüssel für dein Konto. Er ist begrenzt (diese App darf deinen Kalender lesen, nicht löschen), zeitlich befristet (er läuft in einer Stunde ab, nicht nie) und widerrufbar (nimm ihn zurück, ohne deinen Hauptschlüssel neu zu schneiden, also ohne dein Passwort zu ändern). Der Authorization Server ist die Maschine, die diese begrenzten Schlüssel schneidet, und dein Passwort ist der Hauptschlüssel, den du nie herausgibst. Du zeigst ihn nur der einen Stelle, die Parkschlüssel schneiden darf.
Die vier Grant-Types, ehrlich sortiert
OAuth 2.0 ist ein Framework, also definiert es mehrere Wege, an einen Token zu kommen, genannt Grant-Types, für verschiedene Arten von Client. Es hilft, sie danach zu sortieren, wie sehr du ihnen heute trauen solltest:
- Authorization Code ist der wichtigste, unten gezeichnet. Ein kurzlebiger Code wird über einen Back Channel gegen einen Token getauscht, sodass die App deine Zugangsdaten nie berührt. Das nutzt “Mit Google anmelden”. Zusammen mit PKCE ( RFC 7636 ) ist er auch die richtige Wahl für Mobile- und Single-Page-Apps.
- Client Credentials kommt ganz ohne Nutzer aus. Ein Backend authentifiziert sich als es selbst, um einen anderen Dienst zu erreichen: ein Cronjob, der eine API ruft, ein Microservice, der den nächsten ruft. Das ist der Maschine-zu-Maschine-Grant.
- Implicit war eine Abkürzung, die den Token ohne Code-Tausch direkt an den Browser zurückgab, erfunden für JavaScript-Apps, die kein Secret geheim halten konnten. Heute ist er abgeraten; die Security BCP ( RFC 9700 ) sagt, nimm stattdessen den Code-Flow mit PKCE.
- Resource Owner Password Credentials lässt die App deinen Benutzernamen und dein Passwort einsammeln und gegen einen Token tauschen. Das ist OAuth im genau dem Kostüm, das es abschaffen sollte, und es überlebt nur als Migrationskrücke.
Zwei der vier Grant-Types existieren vor allem, damit wir dir sagen können, sie nicht zu nutzen. Modernes OAuth ist eigentlich “der Authorization-Code-Flow mit PKCE”, plus Client Credentials für Maschinen.
Die vier Rollen, vor jedem Flow
Jeder OAuth-Flow ist ein Gespräch zwischen genau vier Parteien. Hast du die klar, hören die Diagramme auf, verwirrend zu sein:
-
Resource Owner meistens du
Der Mensch, dem die Daten gehören und der als Einziger Zugriff darauf gewähren darf. Wenn eine Druck-App nach deinen Fotos fragt, bist du der Resource Owner. Deine Aufgabe ist eine Entscheidung: einmal zustimmen oder ablehnen.
-
Client die fragende App
Die Anwendung, die in deinem Namen handeln will. Ein Confidential Client (ein Web-Backend) kann ein Secret geheim halten; ein Public Client (eine Mobile- oder Single-Page-App) kann das nicht, was ändert, welcher Flow für ihn sicher ist. Der Client sieht dein Passwort nie.
-
Authorization Server stellt die Tokens aus
Wo du dich wirklich anmeldest und zustimmst. Er kennt dein Passwort bereits, also tippst du es nur hier. Nachdem du zugestimmt hast, prägt er den Access Token. Das ist die Anmelde- und Zustimmungsseite von Google, GitHub oder Apple.
-
Resource Server hält die Daten
Die API, die die geschützte Ressource bewacht und den Access Token als Berechtigungsnachweis akzeptiert. Oft dieselbe Firma wie der Authorization Server (Google ist beides), aber nicht immer. Er prüft den Token bei jeder Anfrage.
Ein wichtiges Detail: Authorization Server und Resource Server sind verschiedene Rollen, auch wenn eine Firma beide spielt. Du meldest dich beim einen an und gibst den Token beim anderen aus.
Der Authorization-Code-Flow
Der Ablauf hinter “Mit GitHub anmelden”. Achte darauf, wo sich die zwei Kanäle trennen: der Front Channel läuft durch deinen Browser und trägt nur einen Einmal-Code, während der Back Channel ein direkter Server-zu-Server-Aufruf ist, der den eigentlichen Token trägt. Dein Passwort bleibt die ganze Zeit beim Authorization Server.
Was der RFC wirklich sagt
Das Original ist etwa 76 Seiten lang und liest sich eher wie eine Speisekarte an Optionen als wie ein einzelnes Rezept. Die Landkarte, falls du an der Quelle vorbeischauen willst:
| Abschnitt | In einfachen Worten |
|---|---|
| 1 · Rollen & Protokollablauf | Führt die vier Rollen und den abstrakten Token-Tanz zwischen ihnen ein. Das ist das Vokabular, das der ganze Rest des Webs wiederverwendet, wenn er "Client" oder "Authorization Server" sagt. |
| 1.3–1.5 · Grants & Tokens | Benennt die vier Grant-Types und den Unterschied zwischen Access Token (kurzlebig, der API gezeigt) und Refresh Token (langlebig, privat gehalten, um neue zu holen). |
| 3 · Protokoll-Endpunkte | Die zwei Türen: der Authorization Endpoint (wo du dich anmeldest und zustimmst) und der Token Endpoint (wo ein Code gegen einen Token getauscht wird), plus der Redirection Endpoint des Clients. |
| 4 · Autorisierung erhalten | Jeder Grant-Type, Schritt für Schritt. Abschnitt 4.1 ist der Authorization-Code-Flow, der Teil, den fast jeder tatsächlich implementiert. |
| 6 · Token erneuern | Wie ein Client einen Refresh Token gegen einen frischen Access Token tauscht, wenn der alte abläuft, ohne dich zurück durch die Anmeldeseite zu schleifen. |
| 10 · Sicherheitsbetrachtungen | Ein langes, ehrliches Kapitel darüber, was das Framework allein nicht löst. Genau seine Länge ist der Grund, warum später Best-Practice-Dokumente (RFC 9700) geschrieben werden mussten. |
Was Leute falsch verstehen
-
"Anmelden mit OAuth heißt, OAuth hat mich angemeldet."
Nicht ganz. OAuth 2.0 autorisiert, es authentifiziert nicht. Ein Access Token beweist, dass eine App etwas tun darf, nie wer die Person ist. Die "Wer bist du"-Schicht ist OIDC, eine eigene Spezifikation auf OAuth. "Mit Google anmelden" ist eigentlich OpenID Connect auf OAuth. Einen nackten OAuth-Access-Token als Identitätsnachweis zu behandeln ist ein klassischer und wirklich gefährlicher Fehler.
-
"Der Access Token sagt der App, wer ich bin."
Muss er nicht, und für den Client ist er als undurchsichtig gedacht: eine Zeichenkette, die er dem Resource Server zeigt, nichts, was er auslesen sollte. Aus einem Access Token Identität herauszupulen ist ein Kategorienfehler. Wenn du Identität willst, fragst du über OpenID Connect nach einem ID Token, der ein anderer Token mit einem definierten, prüfbaren Format ist.
-
"OAuth 2.1 hat RFC 6749 schon ersetzt."
Noch nicht. OAuth 2.1 ist weiterhin ein Entwurf, der RFC 6749 mit den Praktiken zusammenfasst, die ihn gehärtet haben (PKCE Pflicht, Implicit- und Password-Grant entfernt). Bis es als RFC veröffentlicht ist, ist 6749 der Standard, und 2.1 ist eine sauberere Neuerzählung desselben Protokolls, kein neues.
-
"Ein Bearer Token ist verschlüsselt, ihn zu loggen ist okay."
Ein Bearer Token (
) ist durch eine Eigenschaft definiert: wer ihn trägt, darf ihn nutzen, wie Bargeld. Er ist nicht zwingend verschlüsselt, und wenn er in eine Logdatei, eine URL oder einen Screenshot durchsickert, kann ihn jeder ausgeben, bis er abläuft. Genau deshalb darf er nur über TLS reisen und niemals in ein Log geschrieben werden.
Wo dir OAuth begegnet
OAuth ist die stille Maschinerie hinter fast jedem 'Konto verbinden'-Moment im Netz. Ein Feldführer zum Erkennen:
| Du siehst | Du schaust vermutlich auf |
|---|---|
| "Mit Google / GitHub anmelden" | OAuth 2.0 macht delegierten Zugriff, mit OpenID Connect obendrauf für den Identitätsteil. Der Button ist das mit Abstand Häufigste, was OAuth antreibt. |
| Ein Zustimmungsbildschirm mit Berechtigungen | "App X möchte: deine E-Mail-Adresse sehen, deine Repositories lesen." Jeder dieser Punkte ist ein OAuth-Scope, den du gleich gewährst. |
| ya29.… oder gho_… | Ein Access Token in freier Wildbahn. Googles beginnen oft mit ya29., GitHub-OAuth-Tokens mit gho_. Eine Zeichenkette, die der Client der API zeigt und ansonsten als undurchsichtig behandelt. |
| kubectl oder gcloud öffnet einen Browser | Der Device Authorization Grant (RFC 8628): OAuth für Dinge, die nicht leicht einen Browser öffnen können. Eine Smart-TV-App, die "geh auf example.com/activate, gib WXYZ ein" zeigt, ist derselbe Flow. |
| GitHub → Einstellungen → Applications | Die Liste der Clients, denen du Tokens gewährt hast, samt Widerruf-Button. Hier wird das Versprechen "widerrufbar" real: ein Klick und der Token ist tot, ohne Passwortänderung. |
| 401 mit WWW-Authenticate: Bearer | Ein Resource Server weist einen fehlenden, abgelaufenen oder falschen Access Token ab. Definiert vom Bearer-Token-Begleiter RFC 6750. |
| Ein API-Key in einem Header | Das, was OAuth nicht ist. Ein statisches geteiltes Secret ohne Nutzer, ohne Scopes und ohne Ablauf per Voreinstellung. Einfacher und gröber, und ein ganz anderes Vertrauensmodell. |
Fragen, die wirklich gestellt werden
Welches Problem löst OAuth 2.0? +
Delegierter Zugriff. Es erlaubt dir, einer App begrenzte, widerrufbare Berechtigung für eine andere zu geben (deinen Kalender lesen, in deinem Namen posten), ohne dein Passwort herauszugeben. Die App bekommt stattdessen einen begrenzten Access Token, den du jederzeit widerrufen kannst, ohne sonst etwas zu ändern.
Ist OAuth 2.0 Authentifizierung oder Autorisierung? +
Strikt Autorisierung: es entscheidet, was eine App darf, nicht wer du bist. Sich damit anzumelden (Authentifizierung) ist eine getrennte Aufgabe, die OpenID Connect obendrauf legt, das auf OAuth 2.0 aufbaut, aber eine eigene Spezifikation ist. Das ist der häufigste OAuth-Irrtum überhaupt.
Was ist der Unterschied zwischen OAuth und OpenID Connect? +
OAuth 2.0 gewährt Zugriff auf Ressourcen (Autorisierung). OpenID Connect ist eine dünne Schicht darüber, die Identität ergänzt (Authentifizierung): es liefert einen ID Token, der der App sagt, wer du bist. 'Mit Google anmelden' ist eigentlich OpenID Connect auf OAuth. 'Dieser App Zugriff auf dein Google Drive geben' ist reines OAuth.
Was ist der Unterschied zwischen OAuth 2.0 und OAuth 2.1? +
OAuth 2.1 ist eine laufende Konsolidierung, noch kein Ersatz. Es fasst RFC 6749 mit den Sicherheitspraktiken zusammen, die ihn gehärtet haben (PKCE verpflichtend, Implicit- und Password-Grant entfernt). Solange es nicht veröffentlicht ist, bleibt RFC 6749 der Standard, und 2.1 ist eine aufgeräumte Neuerzählung, kein neues Protokoll.
Was ist der Unterschied zwischen OAuth 2.0 und SAML? +
Beide delegieren Vertrauen, aber aus verschiedenen Epochen. SAML ist XML-basiert und wurde für Enterprise-Single-Sign-on im Browser gebaut. OAuth 2.0 ist JSON- und HTTP-basiert und wurde für API-Zugriff und Mobile-Apps gebaut. Für das reine Anmelden ist OpenID Connect (auf OAuth) das moderne Gegenstück zu dem, was SAML tat.
Ist OAuth 2.0 noch sicher und aktuell? +
Ja, RFC 6749 ist weiterhin der aktuelle Proposed Standard, aber du musst ihn mit späterer Härtung kombinieren. Nutze den Authorization-Code-Flow mit PKCE (RFC 7636) und folge der OAuth 2.0 Security Best Current Practice (RFC 9700, BCP 240, 2025). Das Framework allein lässt Sicherheitsentscheidungen offen; diese Dokumente schließen die gefährlichen.
Was ist der Unterschied zwischen Access Token und Refresh Token? +
Ein Access Token ist die kurzlebige Berechtigung, die die App der API bei jeder Anfrage zeigt; er verfällt meist in Minuten bis zu einer Stunde. Ein Refresh Token ist eine langlebigere Berechtigung, die die App privat behält, um neue Access Tokens zu holen, ohne dich beim Ablauf zurück durch die Anmeldung zu schicken.
Wie RFC 6749 zusammenhängt
Was vorher kam
-
RFC 5849 (2010) war das ursprüngliche OAuth und verlangte, jede Anfrage kryptografisch zu signieren, was berüchtigt mühsam war. RFC 6749 löst es ab und verlagert die Sicherheitslast auf TLS und ein einfacheres Token-Modell.
Womit es zusammenspielt
-
RFC 9110 · baut auf
Das HTTP, über das alles läuft
Jede OAuth-Nachricht ist eine gewöhnliche HTTP-Anfrage: Redirects, Form-Posts, ein Authorization-Header. OAuth bringt keinen neuen Transport mit, es choreografiert nur HTTP-Anfragen zwischen vier Parteien.
-
RFC 6750 · Begleiter
Wie du den Token tatsächlich benutzt
RFC 6749 sagt, wie man einen Access Token bekommt; sein Zwilling RFC 6750 sagt, wie man ihn einsetzt: in einen <span class="font-mono text-sm">Authorization: Bearer</span>-Header. Bearer heißt, wer ihn hat, darf ihn nutzen, also darf er nur über TLS reisen.
-
RFC 7636 · härtet
PKCE, der Fix für öffentliche Clients
Mobile- und Single-Page-Apps können kein Client-Secret geheim halten, was den Code-Flow früher abfangbar machte. PKCE stopft dieses Loch und ist für solche Clients heute Pflicht. Es ist der Grund, warum der unsichere Implicit-Grant in Rente gehen konnte.
-
RFC 2119 · geschrieben in der Sprache von
Die Schlüsselwörter MUST und SHOULD
Jedes "der Client MUST" und "der Server SHOULD" in RFC 6749 hat eine genaue Bedeutung, die einmal in RFC 2119 festgelegt ist. Die Anforderungen des Frameworks sind nur so stark wie dieses geteilte Vokabular.
Seine Gegenstücke
-
RFC 8252 · aktualisiert durch
OAuth für native Apps
Erweitert RFC 6749 um den richtigen Weg für OAuth in einer Mobile- oder Desktop-App: den System-Browser nutzen, nicht ein eingebettetes WebView, und PKCE verlangen. Eines der Dokumente, die 6749 offiziell aktualisieren.
-
RFC 9700 · aktualisiert durch
Das Sicherheitsregelwerk obendrauf
<span class="text-neutral-500">(BCP 240, 2025)</span> ist die OAuth 2.0 Security Best Current Practice. Sie aktualisiert RFC 6749 formal mit einem Jahrzehnt hart erarbeiteter Ratschläge: Code-Flow mit PKCE nutzen, Implicit- und Password-Grant fallen lassen, Redirect-URIs exakt prüfen.