Site icon bintorosoft.com

OAuth/OIDC-Abuse: Threat Model für moderne Auth

Red Snapper

OAuth/OIDC-Abuse ist eines der wichtigsten Threat-Model-Themen für moderne Authentisierung, weil Angriffe hier selten „laut“ sind: Statt klassische Exploits auszunutzen, missbrauchen Angreifer legitime Protokollflüsse, schlecht konfigurierte Clients oder schwach abgesicherte Identity-Provider-Integrationen. OAuth 2.0 und OpenID Connect (OIDC) ermöglichen Single Sign-on, API-Zugriffe und Delegation über Organisationsgrenzen hinweg. Genau diese Stärke ist auch das Risiko: Token werden zu tragbaren Berechtigungen, Redirects werden zu zentralen Vertrauensanker-Punkten, und Metadaten-Endpunkte können zum Einfallstor werden, wenn Validierung und Bindung fehlen. Ein belastbares Threat Model hilft, die Attack Surface schnell zu strukturieren: Welche Assets sind kritisch (Tokens, Sessions, Claims, Keys)? Welche Trust Boundaries existieren (Browser, Backend, IdP, Drittanbieter-App, API Gateway)? Und wo kann Missbrauch stattfinden (Authorization Endpoint, Token Endpoint, Redirect URI, JWKS, Session-Cookies, Device/Browser-State)? Dieser Artikel beschreibt ein praxistaugliches Threat Model für OAuth/OIDC, ordnet typische Abuse-Patterns ein und zeigt, welche Kontrollen in modernen Plattformen (Web, Mobile, Single Page Apps, Microservices) wirklich zählen.

Warum OAuth und OIDC so häufig missbraucht werden

OAuth 2.0 ist ein Authorization-Framework, das es einem Client ermöglicht, im Namen eines Resource Owners auf Ressourcen zuzugreifen, ohne dass das Passwort an den Client weitergegeben wird. OIDC ergänzt OAuth um Identität: Es definiert u. a. das ID Token, standardisierte UserInfo-Abfragen und Discovery. Missbrauch entsteht oft nicht, weil das Protokoll „unsicher“ wäre, sondern weil Implementierungen und Deployments komplex sind.

Threat-Model-Grundlage: Assets, Akteure und Trust Boundaries

Ein pragmatisches Threat Model startet nicht bei „Attacken“, sondern bei Assets und Vertrauensgrenzen. Damit lassen sich Risiken priorisieren, ohne im Detail zu versinken.

Kritische Assets in OAuth/OIDC

Akteure und typische Angreiferprofile

Trust Boundaries, die Sie explizit zeichnen sollten

Die wichtigsten Abuse-Patterns: Was in der Realität wirklich passiert

Die folgenden Muster tauchen in Incident Response, Bug-Bounty-Reports und Security-Assessments immer wieder auf. Sie sind besonders relevant, weil sie oft ohne klassische Exploits funktionieren.

Redirect URI Abuse: Offene Redirects, Wildcards und Subdomain-Fallen

Die Redirect URI ist ein zentraler Sicherheitsanker: Der Authorization Server leitet Code oder Token dorthin zurück. Wenn Redirect URIs zu großzügig sind (Wildcards, offene Redirect-Endpunkte, unklare Pfadvalidierung), kann ein Angreifer den Rückkanal kapern.

Authorization Code Interception: Missing PKCE und falsche Bindung

Für öffentliche Clients (SPAs, Mobile) ist PKCE praktisch Pflicht. Ohne PKCE kann ein abgefangener Authorization Code oft gegen Tokens getauscht werden. Auch mit PKCE entstehen Risiken, wenn Code Verifier/Challenge nicht sauber gehandhabt werden (z. B. falsches Storage, Logging, Leaks über Referrer oder Crash Reports).

Token Replay und Token Theft: „Bearer“ ohne Bindung

Viele Access Tokens sind Bearer Tokens: Wer das Token besitzt, ist autorisiert. Das macht Token-Diebstahl so attraktiv. Häufige Quellen sind Browser-Storage (LocalStorage), unsichere Mobile-Speicher, Debug-Logs, Proxies, APM/Tracing oder Fehlkonfigurationen, die Tokens in URLs transportieren.

Scope Creep und Over-Privileged Tokens

Ein unterschätzter Klassiker: Clients verlangen mehr Scopes als nötig, weil „es praktisch ist“. Das Threat Model sollte deshalb Scope-Missbrauch als eigenes Risiko führen: Übermäßige Berechtigungen erhöhen Impact, auch wenn der eigentliche Angriff „nur“ ein Token-Leak ist.

Issuer- und Audience-Verwechslung: Token wird für falschen Empfänger akzeptiert

In Multi-IdP- oder Multi-Tenant-Setups passieren Fehler bei iss (Issuer) und aud (Audience). Wenn APIs Tokens akzeptieren, die nicht für sie ausgestellt wurden, entstehen Privilege Escalations und Cross-Tenant-Zugriffe. Besonders riskant ist „lenientes“ Validieren, bei dem nur Signatur geprüft wird, nicht aber alle relevanten Claims.

Algorithm Confusion und Key Handling: Wenn Validierung falsch implementiert ist

Moderne Libraries verhindern viele historische JWT-Fallen, dennoch bleibt Key-Handling ein Risiko: falsches Vertrauen in Header-Felder, fehlerhafte JWKS-Cache-Logik oder Akzeptanz unerwarteter Algorithmen. Im Threat Model sollte daher „Token Validation Failure Modes“ als Kategorie existieren, inklusive Key Rotation und Caching.

OIDC Discovery und SSRF: Metadata als Angriffsfläche

OIDC Discovery (z. B. „.well-known/openid-configuration“) erleichtert Integration, kann aber missbraucht werden, wenn ein System Discovery-URLs aus untrusted Input lädt. Dann kann Discovery zum SSRF-Vektor werden (interne Netze, Cloud-Metadaten) oder zu einer Vertrauensumleitung auf einen Angreifer-IdP.

Flow-spezifisches Threat Modeling: Welche Flows welche Risiken tragen

Ein gutes Threat Model differenziert nach Grant Type, weil die Sicherheitsannahmen stark variieren.

Authorization Code Flow mit PKCE (Web/Mobile/SPA)

Client Credentials Flow (Service-to-Service)

Device Code Flow (TV/CLI/IoT)

Refresh Tokens und Session Persistence

Kontrollpunkte im System: Wo Mitigation technisch ansetzt

Für Umsetzung und Ownership ist hilfreich, Kontrollen entlang der Architektur zu mappen: Authorization Server, Client, Resource Server, Edge/Gateway und Observability.

Authorization Server (IdP) Controls

Client Controls (Web, SPA, Mobile)

Resource Server / API Controls

Edge/Gateway/WAF Controls

Detektion und Telemetrie: Welche Signale OAuth/OIDC-Abuse sichtbar machen

OAuth/OIDC-Abuse ist oft nicht „exploitartig“, daher braucht es Signale, die Missbrauchsmuster abbilden. Ein Threat Model sollte explizit definieren, welche Logs und Metriken für Erkennung und Forensik erforderlich sind.

Ein pragmatischer Coverage-Ansatz für Auth-Telemetrie

Für Teams mit vielen Services ist hilfreich, Coverage messbar zu machen: Haben wir für jeden kritischen Kontrollpunkt mindestens ein verwertbares Signal? Ein einfaches Modell ist die Abdeckung pro Kontrollpunkt als Anteil vorhandener Pflichtsignale.

C = S P

Dabei ist S die Anzahl tatsächlich geloggter Pflichtsignale (z. B. Token-Fehlercodes, Client-ID, Session-ID, Korrelation) und P die definierte Pflichtmenge. Der Wert dient als Steuerungsgröße für Backlogs: Fehlende Signale sind konkret, umsetzbar und auditierbar.

Design-Fallen in modernen Architekturen: SPA, Mobile, Microservices, B2B

OAuth/OIDC-Abuse variiert je nach Architektur. Ein Threat Model sollte deshalb „Architekturprofile“ enthalten, damit Controls nicht nur theoretisch, sondern implementierbar sind.

SPAs und Browser-basierte Risiken

Mobile Apps und Gerätebindung

Microservices und Token-Sprawl

B2B/Föderation und Multi-Tenant

Outbound-Links: Relevante Referenzen für Implementierung und Audits

Threat-Model-Checkliste: Fragen, die Sie in Reviews konsequent stellen sollten

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version