Welche OAuth- und OpenID-Connect-Flows brauche ich – und welche Grant-Typen, Tokenarten und Risiken gehören dazu?

Grundlagen und Bausteine: Rollenmodell, Endpunkte, Parameter, Tokenarten und Claims

Rollenmodell und Vertrauensgrenzen

OAuth 2.0 trennt Verantwortlichkeiten strikt: Die Anwendung, die Zugriff benötigt, ist nicht automatisch die Instanz, die Identitäten bestätigt oder Ressourcen verwaltet. OpenID Connect (OIDC) ergänzt OAuth um standardisierte Authentifizierung und Identitätsinformationen. Präzise Begriffe sind entscheidend, weil sich Sicherheitsannahmen entlang klarer Vertrauensgrenzen bewegen: Wer hält welche Geheimnisse, wer validiert was, und wo entstehen Angriffspunkte wie Token-Diebstahl oder Redirect-Manipulation.

Ein häufiges Missverständnis besteht darin, den „Client“ mit dem Endnutzer oder der „App“ gleichzusetzen. Technisch ist der Client die OAuth-Entität, die Token anfordert; der Endnutzer bleibt der Resource Owner. In OIDC kommt als zusätzliche Rolle der End-User (Subject) hinzu, dessen Identität über den Authorization Server (AS) attestiert wird. Der Resource Server (RS) entscheidet letztlich über den Zugriff auf geschützte Ressourcen; er vertraut dabei entweder direkt den Token-Eigenschaften (z. B. JWT-Claims) oder einer introspektiven Bestätigung durch den AS.

• Resource Owner: Entität, die Zugriffsrechte an Ressourcen besitzt; im Endnutzerfall ist dies typischerweise eine Person, die einer Delegation zustimmt.
• Client: Software, die Token anfordert; Unterscheidung in „confidential“ (kann ein Secret schützen) und „public“ (kann kein Secret schützen), z. B. SPA oder native App.
• Authorization Server (OIDC Provider): Instanz, die den Grant entgegennimmt und Token ausstellt; veröffentlicht Metadaten unter /.well-known/openid-configuration und Schlüsselmaterial typischerweise über jwks_uri.
• Resource Server: API/Backend, das Zugriff anhand von Authorization: Bearer <token> durchsetzt und Token lokal (JWT) oder via Introspection (/introspect) bewertet.

Standard-Endpunkte und ihre Aufgaben

OAuth/OIDC definieren keine einzelnen URL-Pfade, wohl aber Funktionen und Parameter. In OIDC sind die relevanten Endpunkte über Discovery standardisiert auffindbar; OAuth 2.0 selbst wird häufig durch AS-spezifische Metadaten ergänzt. Die wichtigste Sicherheitsregel lautet: Der Client darf Endpunkte nicht „erraten“, sondern sollte sie aus vertrauenswürdig konfigurierten Metadaten beziehen und gegen erwartete Issuer-Informationen absichern.

Parameterfamilien: Sicherheit entsteht aus Korrelation

Viele OAuth/OIDC-Parameter wirken erst im Zusammenspiel. redirect_uri bindet Antworten an einen registrierten Rückkanal; state korreliert Request und Response und schützt gegen CSRF im Browser-Kontext; nonce bindet in OIDC ID Tokens an eine konkrete Authentifizierungsanfrage und reduziert Replay-Risiken. PKCE ergänzt den Authorization-Code-Flow für Public Clients, indem code_challenge/code_verifier den Code-Tausch kryptografisch an die ursprüngliche Anforderung bindet.

• OAuth-Kernparameter: response_type, client_id, redirect_uri, scope, state; am /token zusätzlich grant_type sowie je nach Grant code, refresh_token, device_code.
• OIDC-Erweiterungen: nonce (für ID Token), prompt (z. B. prompt=login), max_age, acr_values (Authentifizierungsstärke), response_mode (Transport der Antwortparameter).
• PKCE: code_challenge und code_challenge_method=S256 an /authorize; code_verifier an /token. Klartext-Methoden ohne Hash gelten als nicht empfehlenswert; S256 ist der etablierte Standard.
• Client-Authentisierung am Token-Endpunkt: typischerweise client_secret_basic (HTTP Basic) oder client_secret_post; in höher abgesicherten Szenarien private_key_jwt oder mTLS-gebundene Clients. Public Clients authentisieren sich nicht mit einem Secret.

Scopes sind kein Identitätsmerkmal, sondern eine Delegationsbeschreibung. Eine API sollte Scopes so schneiden, dass sie minimal, verständlich und überprüfbar bleiben (z. B. payments:read statt admin). Für OIDC gilt: Der Scope openid signalisiert, dass ein ID Token erwartet wird; zusätzliche Scopes wie profile, email steuern die Freigabe von Claims über ID Token und/oder /userinfo.

Tokenarten, Formate und Lebensdauerlogik

OAuth unterscheidet primär zwischen Access Token und Refresh Token. OIDC ergänzt das ID Token als signiertes Authentifizierungsartefakt. Access Tokens sind für den Resource Server bestimmt; Refresh Tokens bleiben beim Client und dienen nur dem Token-Endpunkt. Eine häufige Fehlkonstruktion besteht darin, das ID Token als API-Zugriffstoken zu verwenden: Es adressiert den Client als Audience und trägt Authentifizierungsinformationen, nicht notwendigerweise Autorisierungsentscheidungen für eine Ressource.

Lebensdauerentscheidungen hängen an der Angriffsoberfläche. Browser-basierte Clients mit erhöhtem Exfiltrationsrisiko profitieren von kurzen Access-Token-TTLs und sorgfältig begrenzten Refresh-Mechanismen. Server-seitige Anwendungen können Refresh Tokens robuster absichern, müssen jedoch Token-Leaks über Logs, Traces oder Fehlkonfigurationen verhindern. Unabhängig vom Client-Typ sollte Token-Logging in Klartext unterbunden und die Verarbeitung auf TLS-gesicherte Kanäle beschränkt bleiben.

Claims, Audience, Issuer und die harte Validierung

Claims sind strukturierte Aussagen, die in JWTs oder über /userinfo übertragen werden. Für korrekte Entscheidungen ist die Semantik entscheidend: sub identifiziert den Subject innerhalb eines Issuers, aber nicht global; iss muss exakt dem erwarteten Issuer entsprechen; aud bindet das Token an den vorgesehenen Empfänger. Zeitclaims wie exp und nbf begrenzen Replays, erfordern aber eine definierte Clock-Skew-Politik. Für Access Tokens werden Autorisierungsinformationen oft über Scopes oder domänenspezifische Claims modelliert; diese sollten vom Resource Server streng gegen bekannte Werte und erlaubte Kombinationen geprüft werden.

• Signatur und Schlüsselwahl: Bei JWTs muss der Resource Server die Signatur mit einem Schlüssel aus jwks_uri validieren und kid korrekt auflösen; Algorithmen-Substitution wird durch feste Erwartung eines zulässigen alg reduziert.
• Issuer- und Audience-Prüfung: iss und aud sind zwingend zu validieren; ein Token für einen anderen Client oder einen anderen Issuer darf nicht akzeptiert werden, auch wenn die Signatur technisch gültig ist.
• Replay-Bindungen: OIDC nutzt nonce im ID Token; für Access Tokens können Sender-Constrained-Mechanismen wie mTLS oder DPoP die reine Bearer-Semantik durch Bindung an einen Schlüssel/Transportkanal abschwächen.
• Identitäts- und Kontozuordnung: sub eignet sich für stabile Zuordnung innerhalb des Issuers; falls Multi-Tenant- oder Partner-Setups bestehen, müssen iss und ggf. tenant-spezifische Claims in die Schlüsselbildung einfließen.

Grant-Typen im Detail: Schrittfolgen, Request/Response-Parameter, Tokenformat, Laufzeiten und Refresh-Strategien

Grant-Typen definieren, wie ein Client zu Tokens gelangt, welche Endpunkte beteiligt sind und welche Parameter als Sicherheitsanker dienen. Für belastbare Dokumentation reicht es nicht, nur den „Flow“ zu benennen: Entscheidend sind konkrete Request/Response-Felder, Tokencharakteristika (JWT vs. opaque), Laufzeiten (Access-/Refresh-Token) sowie Refresh- und Rotation-Strategien. Unterschiede entstehen zudem durch Client-Typ (confidential/public), Kanal (Browser-Redirect vs. Backchannel) und das erwartete Bedrohungsmodell (Code-Interception, Token-Diebstahl, Replay, CSRF, Mix-up).

Authorization Code (confidential clients): Sequenz und Parameter

Der Authorization-Code-Grant trennt Frontchannel (Browser-Redirect) und Backchannel (Token-Austausch). Der Client erhält zunächst einen kurzlebigen Code über den Authorization Endpoint und tauscht ihn serverseitig am Token Endpoint gegen Tokens. Diese Entkopplung reduziert die Exposition des Access Tokens im Browser und ermöglicht clientseitige Authentisierung am Token Endpoint. In OpenID Connect wird zusätzlich ein id_token ausgegeben, das Authentifizierungsinformationen enthält und an die Nonces/Claims gebunden werden kann.

Typische Tokenformate: Access Tokens werden häufig als JWT oder opaque ausgegeben. JWTs begünstigen lokale Ressourcenserver-Validierung, erhöhen aber das Risiko unkontrollierter Verbreitung, da Claims ohne Introspection auslesbar sind. Opaque Tokens verlagern Validierung auf Introspection oder Gateway-Validierung, was zentrale Revocation erleichtert. Refresh Tokens sind in der Praxis meist opaque; bei JWT-Refresh-Tokens ist besondere Sorgfalt für Rotation und Widerruf erforderlich.

Authorization Code mit PKCE (public clients, SPA/Mobile): Bindung gegen Code-Interception

PKCE ergänzt den Code-Flow um einen Einmalnachweis, der den Authorization Code an den ursprünglichen Client bindet. Dadurch verliert ein abgefangener code seinen Wert, weil der Angreifer den zugehörigen code_verifier nicht besitzt. PKCE ist für öffentliche Clients (SPAs, native Apps) zwingend; viele Authorization Server erzwingen PKCE mittlerweile generell, auch für confidential clients, um Interception- und Mix-up-Risiken zu reduzieren.

• Authorization Request (PKCE-Felder): code_challenge, code_challenge_method=S256 zusätzlich zu response_type=code, client_id, redirect_uri, scope, state; OIDC: nonce.
• Token Request (PKCE-Nachweis): code_verifier zusätzlich zu grant_type=authorization_code, code, redirect_uri; Client-Authentisierung entfällt bei public clients typischerweise.
• Sicherheitsbindung: Der Authorization Server vergleicht BASE64URL(SHA256(code_verifier)) mit code_challenge; bei S256 sinkt die Angriffsfläche gegenüber plain, das in restriktiven Profilen als nicht akzeptabel gilt.

Refresh-Strategien unterscheiden sich nach Plattform: Native Apps können Refresh Tokens in OS-gestützten Keystores ablegen, während Browser-Umgebungen ein deutlich höheres Exfiltrationsrisiko haben. Für SPAs werden Refresh Tokens nur dann vertretbar, wenn eine strenge Token-Bindung, Rotation und ein Storage-Konzept mit minimaler XSS-Angriffsfläche umgesetzt ist; alternativ reduziert ein BFF-Pattern die Tokenhaltung im Browser, weil Tokens serverseitig verwaltet werden.

Client Credentials (Server-zu-Server): keine Benutzerbindung, klarer Scope-Zuschnitt

Der Client-Credentials-Grant dient der Maschinen-zu-Maschinen-Autorisierung. Es existiert kein Authorization Endpoint und keine Benutzerinteraktion; der Client fordert am Token Endpoint direkt ein Access Token an. Das Token repräsentiert den Client (und ggf. dessen Mandantenkontext), nicht einen Endnutzer. Daraus folgt: Scopes und Audience-Claims müssen so geschnitten sein, dass ein kompromittierter Client nicht in Benutzerrechte „hineinrutschen“ kann.

Bei JWT-Access-Tokens sollten Ressourcenserver strikt iss, aud, exp und Signaturalgorithmus validieren und keine „algorithm confusion“ zulassen. Bei opaque Tokens verschiebt sich die Sicherheitslogik auf Introspection; dort sind Caching, Rate-Limits und ein konsistentes Mapping von Scopes auf Autorisierungsentscheidungen kritisch.

Device Authorization Grant (Device Code): Schrittfolge ohne Browser-Redirect am Gerät

Der Device-Code-Flow adressiert Geräte mit eingeschränkter Eingabe (TVs, IoT, Konsolen). Das Gerät initiiert den Flow am Device Authorization Endpoint, zeigt user_code und verification_uri an, während der Nutzer die Autorisierung auf einem separaten, vollwertigen Gerät durchführt. Das Gerät pollt anschließend den Token Endpoint, bis Autorisierung erfolgt oder der Prozess abläuft. Diese Polling-Phase benötigt serverseitige Schutzmechanismen gegen Missbrauch.

Laufzeiten sind hier besonders sichtbar: device_code ist strikt kurzlebig (gebunden an expires_in), Access Tokens folgen den üblichen Profilen; Refresh Tokens können ausgegeben werden, wenn das Gerätemodell eine sichere Speicherung erlaubt. Sicherheitsimplikationen: user_code muss gegen Erraten geschützt sein (ausreichende Entropie), interval und Rate-Limits dämpfen Polling-Angriffe, und die Verifikations-URI sollte Phishing-resistent gestaltet werden (klare Origin, optional verification_uri_complete zur Reduktion von Eingabefehlern).

Tokenlaufzeiten und Refresh-Strategien über Grant-Typen hinweg

Access Tokens sollten so kurz wie das Betriebsmodell es zulässt, weil ein Bearer Token bei Diebstahl sofort missbraucht werden kann. Refresh Tokens verlagern das Risiko: Sie verlängern Sitzungen und müssen deshalb stärker geschützt werden. Praktikabel ist eine Refresh-Token-Rotation mit Wiederverwendungs-Erkennung, sodass ein gestohlener Refresh Token nach Einsatz typischerweise zur Invalidierung der Token-Familie führt. Für JWT-Access-Tokens ohne zentrale Revocation bleibt die kurze Laufzeit oft die wichtigste Schadensbegrenzung; bei opaque Tokens kann serverseitige Revocation durch Introspection oder Gateway-Policy ergänzen.

• Rotation (Refresh Tokens): Ausgabe eines neuen refresh_token bei Refresh, Invalidierung des vorherigen Tokens; bei Wiederverwendung Erkennung und Sperre der betroffenen Token-Kette.
• Bindung/Hardening (wo verfügbar): Einschränkung durch Client-Authentisierung am Token Endpoint (confidential clients) oder durch kanal-/gerätetypische Schutzmaßnahmen; bei OIDC zusätzlich Prüfung von nonce im id_token.
• Fehlerbehandlung als Sicherheitskontrolle: Strikte Behandlung von invalid_grant bei Code/Refresh-Token, konsequente state-Validierung, und Beachtung von slow_down im Device-Code-Flow zur Vermeidung unnötiger Last und Lockouts.

Sicherheitsimplikationen und Einsatzszenarien: Threats, Fehlkonfigurationen, Schutzmaßnahmen und Vergleichsmatrizen (Web, SPA, Mobile, Server-zu-Server)

OAuth 2.0 und OpenID Connect (OIDC) lösen unterschiedliche Probleme—Autorisierung beziehungsweise Authentifizierung—teilen aber Angriffsflächen entlang derselben Token- und Redirect-Pfade. Die Sicherheitslage ergibt sich weniger aus dem Standardtext als aus konkreten Flussentscheidungen (z. B. Authorization Code mit PKCE vs. implicit-ähnliche Muster), aus Tokenformaten (JWT vs. opaque) und aus Operationalisierung (Schlüsselmanagement, CORS, Logging, Timeouts, Rotation). Sicherheitsimplikationen lassen sich deshalb zuverlässig über Threat-Modeling entlang von Endpunkten und Artefakten strukturieren: /authorize, /token, /jwks, /userinfo, Redirect-URIs, Backchannel-Calls, Refresh-Token-Lebenszyklus und Session-Kopplung.

Threats entlang der Flüsse: von Redirect-Manipulation bis Token-Diebstahl

Die dominanten Risiken entstehen an Übergängen zwischen Browser, App und Authorization Server. Beim Authorization-Endpunkt stehen Redirect-Manipulation und Login-Cross-Site-Request-Forgery (Login-CSRF) im Vordergrund; beim Token-Endpunkt dominieren Credential-Diebstahl, Code-Interception und Fehlkonfigurationen von Client-Authentisierung. Für OIDC kommen Identitätsrisiken hinzu: unzureichende ID-Token-Validierung (Issuer, Audience, Nonce), Verwechslung von Access Token und ID Token sowie Algorithmus- oder Key-Confusion bei JWT-Prüfung. Bei SPAs und Mobile Apps verschärft sich die Lage durch potenziell kompromittierbare Laufzeitumgebungen; bei Server-zu-Server-Flüssen durch zu breite Scopes und langlebige Secrets.

• Authorization-Code-Interception: Abfluss des Parameters code über kompromittierte Redirect-URI, fehlerhafte App-Link-Handling-Ketten oder Proxy-/TLS-Inspection; Gegenmaßnahme: PKCE mit code_verifier/code_challenge und striktes redirect_uri-Matching am /token-Endpoint.
• CSRF und Mix-Up: fehlender oder schwacher state-Wert, Mehr-AS-Setups ohne eindeutige Zuordnung, Referrer-Leaks; Gegenmaßnahme: kryptographisch starker state, Zuordnung im Client-Session-Store, OIDC nonce für ID-Token-Korrelation, nur registrierte Redirect-URIs.
• Token-Diebstahl im Frontchannel: Tokens in URL-Fragmenten oder Query-Strings, Browser-History/Logs/Referrer; Gegenmaßnahme: keine Token-Übergabe im Frontchannel, sondern Code-Flow; Tokens niemals in localStorage persistieren, wenn XSS nicht sicher beherrscht wird.
• XSS/Injection in SPAs: Zugriff auf in JavaScript verfügbare Tokens, Manipulation von Redirect/PKCE-Parametern; Gegenmaßnahme: Content Security Policy, strikte Output-Escaping, Dependency-Härtung, Tokenhaltung in speicherflüchtigen Bereichen und kurze Access-Token-TTL.
• Refresh-Token-Missbrauch: Replay von Refresh Tokens bei Diebstahl, insbesondere bei öffentlichen Clients; Gegenmaßnahme: Refresh-Token-Rotation mit Reuse-Detection, Bindung an Client-Kontext, begrenzte absolute Lebensdauer, Widerrufsstrategie.
• JWT-Validierungsfehler: Akzeptieren falscher iss/aud, fehlende exp-Prüfung, unsichere alg-Akzeptanz, JWKS-Key-Substitution; Gegenmaßnahme: harte Allowlist für iss, erwartete aud, fixierte Algorithmen, Key-Pinning-Strategien wo praktikabel, kontrollierter JWKS-Fetch.

Fehlkonfigurationen, die Sicherheitsgarantien praktisch aushebeln

Viele Vorfälle resultieren aus scheinbar „funktionierenden“ Integrationen mit falschen Defaults. Besonders folgenreich sind überbreite Redirect-URI-Patterns, nicht abgeglichene Redirect-URIs am Token-Endpunkt, sowie das Vermischen von OIDC-Login und API-Autorisierung ohne klare Token-Zweckbindung. In Multi-Tenant-Setups kommen Fehlzuordnungen von Tenant-Identifiers und fehlerhafte Issuer-Validierung hinzu. Auch Operational-Themen sind sicherheitsrelevant: zu lange Token-Lebensdauern, fehlende Rotation von Signierschlüsseln, unzureichende Secrets-Entropie oder Client-Authentisierung an falschen Endpunkten.

Schutzmaßnahmen: Kontrollen für Clients, Token und Transport

Kontrollen greifen am stärksten, wenn sie mehrere Ebenen kombinieren: Protokollparameter (state, nonce, PKCE), Transport (TLS, HSTS), Token-Policy (TTL, Rotation, Audience), sowie Laufzeitkontrollen (Replay-Erkennung, Anomalie-Detektion, Rate Limits). Für Browser-basierte Flüsse ist die strikte Trennung von Frontchannel (nur Code) und Backchannel (Token-Abruf) entscheidend. Für native Apps kommen sichere Redirect-Mechanismen hinzu; gängige Praxis ist die Nutzung systemeigener Browser-Komponenten und registrierter App-Links/Universal Links, um Embedded WebViews als Angriffskanal zu vermeiden. Auf API-Seite entscheidet eine robuste Token-Validierung inklusive Key-Management und Clock-Skew-Handling über die Wirksamkeit aller vorgelagerten Schritte.

• PKCE als Baseline für öffentliche Clients: erzwingen, dass code_challenge_method=S256 verwendet wird; Ablehnung von plain und fehlenden PKCE-Parametern für SPAs und Mobile Apps.
• Client-Authentisierung korrekt wählen: vertrauliche Clients am /token-Endpoint mit private_key_jwt oder mTLS, nicht mit schwachen Shared Secrets; öffentliche Clients ohne Client-Secret.
• Token-Bindung (wo verfügbar): DPoP oder mTLS-gebundene Access Tokens reduzieren Replay-Risiken bei Token-Diebstahl; Implementierung erfordert korrekte Prüfung der cnf-Claims beziehungsweise DPoP-Proof-Header.
• Refresh-Token-Policy: Rotation mit Reuse-Detection, Geräte-/Client-Kontext berücksichtigen, absolute Maximallebensdauer; Logging von Refresh-Reuse als Security-Event.
• Browser-Schutz für SPAs: strikte CSP, Vermeidung von Inline-Skripten, Subresource Integrity für statische Assets, Minimierung von Drittanbieter-Skripten; Tokens bevorzugt nur im Speicher halten.

Vergleichsmatrix: empfohlene Flows pro Einsatzszenario

Die Auswahl eines Flows ist eine Sicherheitsentscheidung über Client-Typ, Geheimnisfähigkeit, Benutzerinteraktion und Angriffsoberfläche. Web-Apps mit Backend können Codes serverseitig einlösen und Tokens vor dem Browser abschirmen. SPAs benötigen PKCE und müssen XSS als primären Risikotreiber behandeln. Mobile Apps erfordern zusätzlich robuste Redirect-Kanäle und eine defensive Haltung gegenüber kompromittierten Geräten. Server-zu-Server-Szenarien nutzen typischerweise Client Credentials; hier verschiebt sich das Risiko auf Secret-Handling, Scope-Disziplin und Schlüsselrotation.