Best Practices für die Absicherung von OAuth in Webanwendungen

OAuth 2.0 hat sich als Standard für die API-Authentifizierung etabliert, doch die sichere Implementierung bleibt eine Herausforderung. Angesichts von Token-Diebstahl, veralteten Flows und browserspezifischen Schwachstellen, die täglich Webanwendungen bedrohen, benötigen Entwickler klare Leitlinien zu dem, was tatsächlich funktioniert. Dieser Artikel behandelt die wesentlichen OAuth 2.0-Sicherheits-Best-Practices, die Sie 2025 benötigen – von RFC 9700-Anforderungen bis hin zu SPA-spezifischen Mustern.

Warum OAuth-Sicherheit wichtiger ist denn je

OAuth schützt die Daten Ihrer Benutzer, indem es die Weitergabe von Passwörtern zwischen Anwendungen eliminiert. Anstatt Drittanbieter-Apps Ihre Zugangsdaten zu geben (wie das Aushändigen Ihrer Hausschlüssel), stellt OAuth temporäre, auf bestimmte Berechtigungen beschränkte Tokens aus – eher wie ein Valet-Schlüssel, der nur das Auto startet.

Aber hier liegt das Problem: Tokens sind wertvolle Ziele. Ein gestohlenes Access-Token gewährt sofortigen API-Zugriff. Schlechte Implementierungsentscheidungen – das Speichern von Tokens in localStorage, die Verwendung veralteter Flows oder das Auslassen von PKCE – verwandeln kleinere Schwachstellen in größere Sicherheitsverletzungen.

Zentrale Sicherheitsrisiken und wie man sie verhindert

Token-Diebstahl und Speicherung

Was Sie nicht tun sollten: Tokens in localStorage oder sessionStorage speichern. Jeder XSS-Angriff kann diese Werte auslesen und an von Angreifern kontrollierte Server übertragen.

Was Sie tun sollten: Bewahren Sie Tokens bei SPAs nur im Arbeitsspeicher auf. Bei serverseitigen Anwendungen speichern Sie sie in verschlüsselten serverseitigen Sessions. Verwenden Sie kurzlebige Access-Tokens (15-30 Minuten), um den Schaden durch Diebstahl zu begrenzen.

Veraltete Flows, die vermieden werden sollten

Der Implicit Flow ist überholt. Sowohl RFC 9700 als auch OAuth 2.1 verbieten ihn. Warum? Weil er Tokens direkt in URL-Fragmenten sendet und sie damit dem Browser-Verlauf, Referrer-Headern und jedem JavaScript auf der Seite aussetzt.

Auch der Resource Owner Password Credentials Flow sollte vermieden werden – er unterläuft den gesamten Zweck von OAuth, indem er von Apps verlangt, Benutzerpasswörter direkt zu verarbeiten.

Verwenden Sie immer: Authorization Code Flow mit PKCE für alle Clients, einschließlich SPAs und mobiler Apps.

Moderne Standards: RFC 9700 und OAuth 2.1

PKCE ist jetzt verpflichtend

PKCE (Proof Key for Code Exchange) verhindert Angriffe durch Abfangen von Authorization Codes. So funktioniert es:

// Generate code verifier and challenge
const verifier = generateRandomString(128);
const challenge = base64url(sha256(verifier));

// Include challenge in authorization request
const authUrl = `https://auth.example.com/authorize?` +
  `client_id=app123&` +
  `code_challenge=${challenge}&` +
  `code_challenge_method=S256`;

// Send verifier when exchanging code for token
const tokenResponse = await fetch('/token', {
  method: 'POST',
  body: JSON.stringify({
    code: authorizationCode,
    code_verifier: verifier
  })
});

OAuth 2.1 macht PKCE für alle Authorization Code Flows verpflichtend, nicht nur für öffentliche Clients.

Token-Binding mit mTLS oder DPoP

Token-Binding stellt sicher, dass gestohlene Tokens nicht von Angreifern verwendet werden können. Zwei Hauptansätze:

• mTLS (Mutual TLS): Bindet Tokens an Client-Zertifikate
• DPoP (Demonstrating Proof of Possession): Verwendet kryptografischen Nachweis ohne Zertifikate

Beide verhindern Token-Replay-Angriffe, indem sie Tokens kryptografisch an den legitimen Client binden.

Refresh-Token-Rotation

Verwenden Sie Refresh-Tokens niemals mehrfach. Jede Aktualisierung sollte ein neues Refresh-Token ausstellen und das alte ungültig machen. Dies begrenzt das Zeitfenster für den Missbrauch gestohlener Refresh-Tokens:

// Server-side refresh token handling
async function refreshAccessToken(oldRefreshToken) {
  // Validate and revoke old refresh token
  await revokeToken(oldRefreshToken);
  
  // Issue new token pair
  return {
    access_token: generateAccessToken(),
    refresh_token: generateRefreshToken(), // New refresh token
    expires_in: 1800
  };
}

SPA-OAuth-Sicherheit: Besondere Überlegungen

Single-Page-Anwendungen stehen vor einzigartigen Herausforderungen, da der gesamte Code im Browser läuft. Der Browser ist feindliches Territorium – gehen Sie davon aus, dass alle dort befindlichen Daten kompromittiert werden können.

Backend for Frontend (BFF)-Muster

Der sicherste Ansatz hält Tokens vollständig aus dem Browser heraus. Ein leichtgewichtiges Backend-Proxy verarbeitet OAuth-Flows und verwaltet Tokens serverseitig, wobei sichere, httpOnly, sameSite-Cookies für die SPA-Session verwendet werden.

Token-Handler-Muster

Für Teams, die SPA-Vorteile ohne Backend-Komplexität wünschen, bietet das Token-Handler-Muster einen Mittelweg. Es verwendet einen spezialisierten Proxy, der:

• OAuth-Flows verarbeitet
• Tokens sicher speichert
• Kurzlebige Session-Cookies an die SPA ausgibt
• Cookie-authentifizierte Anfragen in token-authentifizierte API-Aufrufe übersetzt

Falls Sie Tokens im Browser speichern müssen

Wenn BFF nicht umsetzbar ist:

• Speichern Sie Tokens nur im Arbeitsspeicher, niemals in localStorage
• Verwenden Sie Service Workers, um den Token-Zugriff zu isolieren
• Implementieren Sie aggressive Token-Ablaufzeiten (5-15 Minuten)
• Speichern Sie niemals Refresh-Tokens im Browser

Implementierungs-Checkliste

✓ Verwenden Sie Authorization Code Flow mit PKCE für alle Clients
✓ Implementieren Sie exakte Redirect-URI-Übereinstimmung
✓ Setzen Sie Token-Laufzeiten auf minimal praktikable Dauern
✓ Aktivieren Sie Refresh-Token-Rotation für öffentliche Clients
✓ Verwenden Sie den State-Parameter für CSRF-Schutz
✓ Implementieren Sie Token-Binding (mTLS/DPoP) für Hochsicherheitsanwendungen
✓ Für SPAs: Erwägen Sie BFF- oder Token-Handler-Muster
✓ Überwachen Sie OAuth 2.1-Compliance-Anforderungen

Fazit

Die Absicherung von OAuth in Webanwendungen erfordert ein Verständnis sowohl der Stärken des Protokolls als auch der spezifischen Bedrohungen für Ihre Architektur. Beginnen Sie mit den Anforderungen von RFC 9700: verpflichtendes PKCE, kein Implicit Flow und ordnungsgemäße Token-Handhabung. Für SPAs sollten Sie ernsthaft erwägen, Tokens durch BFF- oder Token-Handler-Muster vollständig aus dem Browser herauszuhalten. Dies sind nicht nur Best Practices – sie sind die Mindestanforderung für OAuth-Sicherheit im Jahr 2025.

FAQs

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.