OAuth-2.0-Flussdiagramm: Authorization Code mit PKCE, Schritt für Schritt

OAuth 2.0 ist leicht zu benutzen und schwer vorzustellen. Ein Login-Button löst Weiterleitungen zwischen drei oder vier Parteien aus, jede mit Parametern ähnlichen Namens, und die meisten Bugs entstehen, weil eine Partei eine Prüfung auslässt, die sie hätte machen sollen. Ein Sequenzdiagramm zeigt am klarsten, wer wem was in welcher Reihenfolge schickt.

Dieser Beitrag zeichnet den Flow, den du heute für fast jeden Client nutzen solltest: den Authorization Code Grant mit PKCE. Er geht jeden Schritt durch, erklärt, was jede Partei prüft, und listet die älteren Flows auf, die du laut aktuellen Empfehlungen aufgeben solltest.

Die vier Parteien

Der Client sieht nie das Passwort des Nutzers. Genau darum geht es bei OAuth: Der Autorisierungsserver authentifiziert den Nutzer und gibt dem Client ein Token mit begrenztem Scope und begrenzter Laufzeit.

Welcher Flow im Jahr 2026

Das ursprüngliche OAuth-2.0-Framework, RFC 6749, definierte mehrere Grants. Die im Januar 2025 veröffentlichte OAuth 2.0 Security Best Current Practice, RFC 9700, schränkt die Wahl ein:

• Authorization Code mit PKCE für die Nutzeranmeldung, aus jeder Art von Client. Öffentliche Clients (Mobile-Apps, Single-Page-Apps) müssen PKCE nutzen; für vertrauliche Clients mit serverseitigem Secret wird es empfohlen.
• Nicht den Implicit Grant. Er gibt Tokens in der Browser-Weiterleitung zurück, wo sie durchsickern können; Clients sollten ihn nicht nutzen.
• Nicht den Resource Owner Password Credentials Grant. Das Passwort des Nutzers an den Client zu geben, verfehlt den Zweck; die BCP sagt, er darf nicht verwendet werden.
• Client Credentials für Service-zu-Service-Aufrufe ohne beteiligten Nutzer.

Der Entwurf für OAuth 2.1 fasst diese Regeln in einem Dokument zusammen, daher setzen neue Bibliotheken sie zunehmend voraus.

PKCE in einem Absatz

Proof Key for Code Exchange, RFC 7636, schützt den Authorization Code. Vor der Weiterleitung erzeugt der Client einen zufälligen code_verifier (43 bis 128 Zeichen) und sendet nur dessen SHA-256-Hash, die code_challenge, mit code_challenge_method=S256. Wenn der Client den Code später gegen Tokens tauscht, sendet er den Verifier. Der Server hasht ihn und vergleicht. Ein Angreifer, der den Code abfängt, kann ihn ohne den Verifier nicht nutzen, und der hat den Client nie verlassen.

Der Flow, Schritt für Schritt

1. Der Nutzer klickt auf Anmelden. Der Client erzeugt state (einen zufälligen Wert, der an die Sitzung des Nutzers gebunden ist) sowie den PKCE-Verifier und die Challenge.
2. Der Client leitet zu /authorize weiter, mit response_type=code, client_id, der registrierten redirect_uri, dem angefragten scope, state und der Code Challenge.
3. Der Autorisierungsserver zeigt seine Login- und Einwilligungsseite. Der Client ist nicht beteiligt; das passiert auf der Domain des Servers.
4. Der Nutzer meldet sich an, schließt bei Bedarf MFA ab und willigt in die Scopes ein.
5. Der Server leitet zurück zur exakt registrierten redirect_uri, mit einem kurzlebigen, einmal verwendbaren code und demselben state. Der Client prüft, ob state zu dem passt, was er gesendet hat; wenn nicht, bricht er ab. RFC 6749 empfiehlt eine Code-Laufzeit von höchstens 10 Minuten.
6. Der Client sendet einen POST an /token mit dem Code, der Redirect-URI und dem code_verifier (plus seiner Client-Authentifizierung, falls er ein vertraulicher Client ist). Das ist ein Back-Channel-Request, keine Weiterleitung.
7. Der Server gibt Tokens zurück: ein Access Token, meist ein Refresh Token und ein ID Token, wenn du OpenID Connect nutzt.
8. Der Client ruft die API auf, mit Authorization: Bearer <access token>.
9. Die API validiert das Token und antwortet. Bei JWT-Access-Tokens prüft sie Signatur, Aussteller, Audience, Ablauf und Scopes lokal; bei opaken Tokens fragt sie den Introspection-Endpunkt des Autorisierungsservers.
10. Wenn das Access Token abläuft, sendet der Client das Refresh Token per POST an /token.
11. Der Server gibt ein neues Access Token zurück, bei öffentlichen Clients auch ein neues Refresh Token. RFC 9700 verlangt, dass Refresh Tokens öffentlicher Clients entweder an den Absender gebunden sind oder rotiert werden, sodass ein gestohlenes Refresh Token nach einer Nutzung durch eine der Parteien nicht mehr funktioniert.

Das Sequenzdiagramm

So liest du es:

• Vier Lebenslinien, von links nach rechts: der Nutzer, die Client-App, der Autorisierungsserver und die API.
• Durchgezogene Pfeile mit gefüllter Spitze sind Anfragen; gestrichelte Pfeile sind Antworten und Rückleitungen.
• Schritte 2 bis 5 sind Front-Channel-Weiterleitungen über den Browser; Schritt 6 ist der Back-Channel-Token-Request, in dem sich PKCE auszahlt.
• Das opt-Fragment unten läuft nur, wenn das Access Token abgelaufen ist.
• Der Markdown-Block listet die Prüfungen jeder Partei; dort verstecken sich die meisten echten Bugs.

Fehler, die in Reviews auftauchen

• state nicht prüfen. Ohne diese Prüfung kann ein Angreifer im Browser des Opfers einen Login-Flow mit dem Konto des Angreifers abschließen.
• Lockerer Abgleich der Redirect-URI. Der Server muss exakt mit der registrierten URI vergleichen; Präfix- oder Wildcard-Abgleich ermöglicht Code-Diebstahl.
• Tokens im Local Storage einer Single-Page-App. Jede Script-Injection kann sie lesen. Viele Teams setzen ein kleines Backend vor die SPA (ein Backend-for-Frontend), das die Tokens hält und dem Browser ein Session-Cookie gibt.
• APIs, die jedes gültige Token akzeptieren. Prüfe die Audience, sonst funktioniert ein für eine andere API ausgestelltes Token auch bei deiner.
• Eingebettete Webviews in Mobile-Apps. RFC 8252 sagt, native Apps sollten den Systembrowser nutzen, damit die App die Zugangsdaten des Nutzers nicht sehen kann.
• Langlebige Access Tokens, um Refresh-Logik zu vermeiden. Halte Access Tokens kurz und erneuere sie; dann greift ein Widerruf schnell.

Was in ein OAuth-Diagramm gehört

• Jede Partei als eigene Lebenslinie, einschließlich des Browsers, wenn dein Client ein Backend hat.
• Front Channel und Back Channel unterschieden, weil sie unterschiedliche Sicherheitseigenschaften haben.
• Parameternamen an den Pfeilen: state, code_challenge, code, code_verifier. Reviewer suchen danach.
• Wer was validiert. Die Prüfungen sind das Design; die Pfeile bewegen nur Daten.

Wenn du das größere Sicherheitsbild zeichnest, zeigt das Zero-Trust-Architekturdiagramm, wo der Identity Provider zwischen den anderen Kontrollen sitzt, und das Architekturdiagramm für API-Gateways behandelt die einmalige Token-Validierung an der Edge. Das Beispiel für ein Sequenzdiagramm erklärt die hier verwendete Notation genauer.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem Sequenz-Pack einen Akteur für den Nutzer und drei Lebenslinie-Nodes für Client-App, Autorisierungsserver und API hinzu, in einer Reihe und gleich hoch.
3. Zeichne jede Nachricht als gerade Kante zwischen den Lebenslinien, von oben nach unten, mit den Parameternamen im Label. Nutze gestrichelte Kanten mit offenen Pfeilspitzen für Antworten und Weiterleitungen.
4. Füge um die Refresh-Schritte ein Kombiniertes Fragment mit dem Operator opt hinzu.
5. Füge einen Markdown-Block aus dem Basis-Pack mit den Prüfungen jeder Partei hinzu.

Das Beispiel nutzt 6 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist der Unterschied zwischen OAuth 2.0 und OpenID Connect? Bei OAuth 2.0 geht es um delegierten Zugriff: Der Client bekommt ein Token, um eine API aufzurufen. OpenID Connect ergänzt Identität: ein ID Token, das dem Client sagt, wer der Nutzer ist, und einen standardisierten Userinfo-Endpunkt.

Brauche ich PKCE, wenn meine App ein Client Secret hat? RFC 9700 empfiehlt es auch für vertrauliche Clients. Es schützt vor Code-Injection und kostet auf jeder Seite einen zusätzlichen Parameter.

Sollte der Implicit Grant noch verwendet werden? Nein. Die aktuelle Best Practice sagt, Clients sollten ihn nicht nutzen. Nimm stattdessen den Authorization Code Grant mit PKCE, auch in Single-Page-Apps.

Wo sollte eine Single-Page-App Tokens speichern? Am besten gar nicht im Browser: Ein Backend-for-Frontend kann Tokens serverseitig halten und dem Browser ein sicheres Session-Cookie geben. Wenn Tokens im Browser liegen müssen, halte sie im Speicher, halte Access Tokens kurz und nutze Refresh-Token-Rotation.

Wie validiert die API ein Access Token? Bei JWT-Access-Tokens durch Prüfung der Signatur mit den veröffentlichten Schlüsseln des Autorisierungsservers sowie von Aussteller, Audience, Ablauf und Scope. Bei opaken Tokens durch einen Aufruf des Introspection-Endpunkts.

Kostenlos starten — ein Seat, keine Kreditkarte.