OpenID Connect & OAuth 2.0, zum Durchklicken

Der Client würfelt seine Einmalwerte

Bevor überhaupt etwas über die Leitung geht, erzeugt die Anwendung drei Zufallswerte. Der code_verifier bleibt geheim im Client; nur sein SHA-256-Abdruck (die code_challenge) geht mit auf die Reise. Damit ist ein abgefangener Autorisierungscode für einen Angreifer wertlos: Ohne den Verifier kann er ihn nicht einlösen. Die Werte hier sind echt gerechnet – die Challenge ist der tatsächliche Base64url-kodierte SHA-256 des Verifiers darüber.

Weiterleitung zum Autorisierungsserver

Die Anwendung schickt den Browser des Nutzers zum Autorisierungsendpunkt – als ganz normale Weiterleitung. Alles, was hier steht, ist für den Nutzer sichtbar und steht im Browserverlauf: Diese Strecke ist der Front-Channel. Geheimnisse haben hier nichts verloren, deshalb geht auch nur die Challenge mit und nicht der Verifier.

?response_type=code
  &client_id=
  &redirect_uri=
  &scope=
  &state=
  &nonce=
  &code_challenge=
  &code_challenge_method=S256

Der redirect_uri muss beim Provider vorab registriert sein und exakt übereinstimmen – Zeichen für Zeichen, inklusive Schrägstrich am Ende. Das ist kein Schikane, sondern die einzige Bremse dagegen, dass jemand den Code auf seinen eigenen Server umleitet.

Der Nutzer meldet sich an – beim Provider, nicht bei der Anwendung

Jetzt passiert der Teil, von dem die Anwendung nichts mitbekommt und nichts mitbekommen soll: Passwort, zweiter Faktor, Passkey, Zustimmungsdialog. Der Client sieht davon nichts – das ist der eigentliche Gewinn des Verfahrens. Besteht beim Provider schon eine Sitzung, läuft dieser Schritt unsichtbar durch, und genau das ist Single Sign-on.

Weil der Provider seine eigene Sitzung in einem Cookie hält, hängt die stille Erneuerung im Hintergrund (prompt=none im versteckten iframe) an Drittanbieter-Cookies – die Browser schalten sie gerade ab. Der vorgesehene Ersatz sind Refresh Tokens mit Rotation.

Rücksprung mit dem Autorisierungscode

Der Provider schickt den Browser zurück zur registrierten Adresse und hängt den Code an. Der Code ist kurzlebig (meist eine Minute) und genau einmal einlösbar; er selbst ist noch kein Zugang zu irgendetwas. Er steht in der Adressleiste, im Verlauf und womöglich im Server-Log – genau deshalb ist er nur die halbe Miete und braucht im nächsten Schritt den Verifier dazu.

HTTP/1.1 302 Found
Location: ?code=
  &state=
  &iss=

Hier wird der state geprüft, und zwar bevor irgendetwas anderes passiert. Fehlt er oder passt er nicht zur Sitzung, bricht der Client ab. Der Vergleich sollte zeitkonstant sein, und der gespeicherte Wert danach gelöscht – sonst ist er wiederverwendbar.

Code gegen Tokens tauschen

Dieser Aufruf geht direkt vom Client zum Provider, ohne Browser dazwischen: der Back-Channel. Hier wird der code_verifier nachgereicht. Der Provider bildet selbst den SHA-256 darüber und vergleicht ihn mit der Challenge aus Schritt 2. Passt es nicht, gibt es keine Tokens – selbst wenn der Code korrekt ist.

POST  HTTP/1.1
Host: 
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=
&redirect_uri=
&client_id=
&code_verifier=

Ein client_secret gehört ausschließlich in Clients, die es geheim halten können: Server-Anwendungen. In einer SPA oder einer Mobile-App ist es nach dem ersten Blick in den Netzwerk-Tab bzw. in das entpackte Paket kein Geheimnis mehr. Genau dafür gibt es PKCE – ein öffentlicher Client ohne Secret ist damit trotzdem sicher.

Die Antwort: drei Tokens mit drei Aufgaben

Der Provider antwortet mit einem JSON-Objekt. Die drei Tokens darin werden ständig verwechselt, haben aber völlig verschiedene Empfänger: Das ID-Token ist für den Client und sagt, wer sich angemeldet hat. Das Access Token ist für die API und sagt, was erlaubt ist – der Client soll es gar nicht lesen. Das Refresh Token ist für den Provider und dient nur dazu, neue Tokens zu bekommen.

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "",
  "access_token": "",
  "refresh_token": "",
  "id_token": ""
}

Das ID-Token unten ist ein echtes, zur Laufzeit in deinem Browser signiertes RS256-Token, kein Textbaustein – inklusive korrekt gerechnetem at_hash über das Access Token.

ID-Token prüfen (und das ist Pflicht)

Ein ID-Token, das man nicht prüft, ist eine Behauptung. Die Prüfung ist der Punkt, an dem aus einem Stück Base64 eine belastbare Aussage über eine Identität wird – und sie ist die häufigste Stelle, an der Eigenbau-Integrationen scheitern. Bibliotheken nehmen einem das ab; wer es selbst baut, muss jeden Punkt dieser Liste abhaken.

Den Algorithmus immer selbst vorgeben, nie aus dem Header des Tokens übernehmen. Sonst schickt ein Angreifer alg: none oder tauscht RS256 gegen HS256 und signiert mit dem öffentlichen Schlüssel, den er ohnehin kennt.

UserInfo abfragen – oft überflüssig

Der UserInfo-Endpunkt liefert dieselben Claims noch einmal, diesmal gegen Vorlage des Access Tokens. Sinnvoll ist er, wenn die Angaben aktuell sein müssen oder das ID-Token schlank bleiben soll – manche Provider liefern Standard-Claims überhaupt nur hier. Enthält das ID-Token bereits alles Benötigte, ist dieser Aufruf ein zusätzlicher Roundtrip ohne Gewinn.

GET  HTTP/1.1
Host: 
Authorization: Bearer 

HTTP/1.1 200 OK
Content-Type: application/json

{
  "sub": "",
  "name": "",
  "given_name": "",
  "family_name": "",
  "email": "",
  "email_verified": true,
  "locale": ""
}

Der sub-Wert aus der Antwort muss dem sub aus dem ID-Token entsprechen. Tut er das nicht, wurden zwei verschiedene Personen vermischt – die Antwort ist dann zu verwerfen.

Nachschub holen, ohne den Nutzer zu stören

Läuft das Access Token ab, tauscht der Client das Refresh Token gegen ein frisches Paar. Für den Nutzer passiert dabei sichtbar nichts. Der angefragte scope darf dabei kleiner werden, aber niemals größer als beim ursprünglichen Zugriff.

POST  HTTP/1.1
Host: 
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token=
&client_id=
&scope=

Öffentliche Clients müssen Refresh Tokens rotieren: Bei jeder Nutzung gibt es ein neues, das alte verfällt. Taucht ein bereits verbrauchtes Token noch einmal auf, wurde es gestohlen – der Provider zieht dann die ganze Kette ein. Genau deshalb gehört ein Refresh Token in einem Browser niemals in localStorage.

Das Gerät fragt nach einem Code

Ein Fernseher hat keine brauchbare Tastatur und oft gar keinen Browser. Statt den Nutzer dort tippen zu lassen, holt sich das Gerät zwei Codes und verlagert die Anmeldung auf ein Gerät, das dafür taugt – das Telefon in der Hosentasche.

POST  HTTP/1.1
Host: 
Content-Type: application/x-www-form-urlencoded

client_id=
&scope=

Zwei Codes: einer für den Menschen, einer für die Maschine

Der user_code ist kurz und absichtlich leicht abzutippen – meist ohne die Zeichen, die man verwechselt. Er wird auf dem Bildschirm angezeigt. Der device_code ist lang, wird nie angezeigt und ist der Wert, mit dem das Gerät gleich pollt.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "device_code": "",
  "user_code": "",
  "verification_uri": "",
  "verification_uri_complete": "",
  "expires_in": 900,
  "interval": 5
}

Die verification_uri_complete enthält den user_code bereits – ideal als QR-Code auf dem Fernseher. Der Nutzer scannt und muss nichts mehr eintippen.

Der Nutzer erledigt die Anmeldung auf dem Telefon

Auf dem Telefon läuft der ganz normale Anmeldeablauf inklusive zweitem Faktor – mit richtiger Tastatur, vertrautem Browser und sichtbarer Adresszeile. Das Gerät im Wohnzimmer sieht davon nichts und bekommt nie ein Passwort zu Gesicht.

Die Schwachstelle des Verfahrens ist Phishing: Ein Angreifer startet den Flow selbst und bringt sein Opfer dazu, dessen Code zu bestätigen. Deshalb muss die Zustimmungsseite deutlich benennen, welches Gerät gerade Zugriff bekommt – und der Flow gehört nur auf Geräte, die ihn wirklich brauchen.

Das Gerät fragt im Takt nach

Währenddessen fragt das Gerät den Token-Endpunkt in regelmäßigen Abständen, ob der Nutzer fertig ist. Die Antwort ist so lange ein Fehler – und der ist hier keine Störung, sondern der vorgesehene Zustand.

POST  HTTP/1.1
Host: 
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:device_code
&device_code=
&client_id=

HTTP/1.1 400 Bad Request

{ "error": "authorization_pending" }

slow_down ist kein Vorschlag: Der Abstand muss danach um mindestens fünf Sekunden wachsen, sonst sperrt der Provider den Versuch.

Zustimmung erteilt – Tokens für das Gerät

Sobald der Nutzer auf dem Telefon zugestimmt hat, beantwortet der nächste Poll-Versuch sich selbst: Das Gerät bekommt Access Token, Refresh Token und – bei scope=openid – ein ID-Token. Ab hier unterscheidet es sich in nichts mehr vom Code-Flow.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "token_type": "Bearer",
  "expires_in": 3600,
  "access_token": "",
  "refresh_token": "",
  "id_token": ""
}

Weil Geräte selten erneut angemeldet werden können, sind Refresh Tokens hier besonders langlebig. Sie liegen auf einem Gerät im Wohnzimmer – die Möglichkeit, sie zentral zurückzuziehen, ist damit Pflicht und nicht Kür.

Ein Dienst weist sich selbst aus

Kein Browser, kein Nutzer, keine Weiterleitung: Ein Hintergrunddienst braucht Zugriff auf eine API und authentisiert sich dafür mit seinen eigenen Zugangsdaten. Der ganze Flow ist ein einziger HTTP-Aufruf. Die client_id ist hier die Identität, es gibt keine Person dahinter.

POST  HTTP/1.1
Host: 
Authorization: Basic 
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&scope=invoices.read

Die Zugangsdaten gehören in Basic Auth oder – besser – in ein signiertes Client-Assertion-JWT (private_key_jwt). Dann verlässt das Geheimnis den Dienst nie, und ein mitgelesener Aufruf enthält nichts Wiederverwendbares.

Ein Access Token – und sonst nichts

Die Antwort enthält nur ein Access Token. Kein ID-Token, kein Refresh Token, und das ist kein Versehen des Providers, sondern richtig so: Ein ID-Token bezeugt, dass sich ein Mensch angemeldet hat. Hier hat sich niemand angemeldet. Ein Refresh Token wäre ebenso sinnlos – der Dienst kennt sein Geheimnis und kann sich jederzeit ein neues Token holen.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "invoices.read",
  "access_token": ""
}

Deshalb ist dieser Flow kein OpenID Connect, sondern reines OAuth 2.0. Wer hier scope=openid schickt, bekommt je nach Provider einen Fehler oder ein ID-Token ohne Aussagewert.

Tokens direkt anfordern – der alte Weg

Vor PKCE konnte eine reine Browser-Anwendung den Token-Endpunkt nicht sicher ansprechen: Ein client_secret hätte im Quelltext gestanden, und CORS gab es noch nicht überall. Die Antwort darauf war, die Tokens gleich mit der Weiterleitung auszuliefern – ohne zweiten Schritt.

?response_type=id_token%20token
  &client_id=
  &redirect_uri=
  &scope=
  &state=
  &nonce=

Der Zwischenweg response_type=code id_token heißt Hybrid Flow: Das ID-Token kommt sofort, der Code wird wie gewohnt getauscht. Man trifft ihn noch bei OpenID-Connect-Implementierungen der ersten Stunde und bei Microsoft-Entra-Konfigurationen.

Die Tokens stehen in der Adresszeile

Der Teil hinter dem # wird zwar nicht an den Server geschickt, ist aber alles andere als geschützt: Er steht im Browserverlauf, wird von jedem Skript auf der Seite gelesen, landet in Erweiterungen und wird beim Teilen eines Links mitkopiert. Ein Access Token, das durch eine Adresszeile gereicht wurde, muss als kompromittiert gelten.

HTTP/1.1 302 Found
Location: #access_token=
  &token_type=Bearer
  &expires_in=3600
  &id_token=
  &state=

Ein Refresh Token gibt es hier nicht – wenn das Access Token abläuft, war die einzige Lösung ein verstecktes iframe mit prompt=none. Das scheitert heute an den Drittanbieter-Cookie-Regeln der Browser und ist damit auch praktisch am Ende.

Warum davon abgeraten wird – und was stattdessen gilt

Die aktuelle Empfehlung der IETF (OAuth 2.0 Security Best Current Practice) ist eindeutig: Der Implicit Flow soll nicht mehr verwendet werden, und in OAuth 2.1 fehlt er schlicht. Für jede Art von Browser-Anwendung gilt heute Authorization Code mit PKCE – dasselbe Verfahren wie für Server-Anwendungen, nur ohne client_secret.

Wenn du auf eine bestehende Integration mit response_type=token triffst: Das ist der Umstellungsgrund, nicht bloß eine Modernisierung. Der Weg dahin ist meist kurz, weil jede aktuelle Bibliothek Code+PKCE ohnehin als Standard fährt.