OAuth 2.0 & OIDC: Sicherheit moderner Authentifizierung

OAuth 2.0 in einfachen Worten

OAuth 2.0 ist ein Autorisierungs-Framework, kein Authentifizierungsprotokoll. Dieser Unterschied ist enorm wichtig: OAuth beantwortet die Frage "Auf was darf diese Anwendung zugreifen?" – nicht "Wer ist dieser Benutzer?". Sein Hauptanwendungsfall ist delegierter Zugriff: einer Drittanbieter-App zu erlauben, Ihre Google Drive-Dateien zu lesen, ohne jemals Ihr Google-Passwort zu sehen.

Die Kernakteure in OAuth:

• Resource Owner: der Benutzer, dem die Daten gehören
• Client: die Drittanbieter-Anwendung, die Zugriff anfordert
• Authorization Server: stellt Token aus, nachdem der Benutzer zugestimmt hat (z. B. Googles Auth-Server)
• Resource Server: die API, die die Benutzerdaten enthält (z. B. Google Drive API)

Der Authorization Server stellt ein Access Token aus, das der Client verwendet, um den Resource Server im Namen des Benutzers aufzurufen. Token sind typischerweise kurzlebige JWTs oder opake Zeichenketten.

Der Authorization Code Flow

Für serverseitige Webanwendungen ist der Authorization Code Flow der empfohlene Ansatz:

1. Client leitet den Benutzer zum Authorization Server weiter mit response_type=code, client_id, redirect_uri, scope und einem zufälligen state-Parameter
2. Benutzer authentifiziert sich und erteilt Zustimmung
3. Authorization Server leitet zurück zur redirect_uri des Clients mit einem kurzlebigen code und dem state-Wert
4. Client überprüft, ob der state mit dem gesendeten übereinstimmt (CSRF-Schutz), tauscht dann den code gegen Token über eine Back-Channel-POST-Anfrage unter Verwendung seines client_secret aus
5. Authorization Server gibt access_token und optional refresh_token und id_token zurück

Der Back-Channel-Austausch (Schritt 4) macht diesen Flow sicher – das Access Token wird niemals in der URL oder im Verlauf des Browsers angezeigt.

PKCE: Öffentliche Clients absichern

Mobile Apps und SPAs (Single-Page Applications) können ein client_secret nicht sicher aufbewahren – es wäre in der App-Binärdatei oder im JavaScript-Quellcode sichtbar. PKCE (Proof Key for Code Exchange, ausgesprochen "Pixie") löst dieses Problem:

1. Client generiert einen zufälligen code_verifier und leitet daraus code_challenge = BASE64URL(SHA256(code_verifier)) ab
2. code_challenge wird in der Autorisierungsanfrage gesendet
3. code_verifier wird beim Token-Austausch gesendet
4. Authorization Server überprüft die Beziehung – nur der ursprüngliche Client kann den Austausch abschließen

PKCE sollte für alle OAuth-Clients verwendet werden, einschließlich vertraulicher Clients. Es bietet Schutz, selbst wenn der Autorisierungscode abgefangen wird.

OpenID Connect (OIDC): Authentifizierung hinzufügen

OIDC ist eine dünne Identitätsschicht, die auf OAuth 2.0 aufgebaut ist. Es fügt das ID Token hinzu – ein JWT, das vom Authorization Server signiert ist und Angaben über den authentifizierten Benutzer enthält (sub, email, name usw.). OIDC ist das, was "Mit Google anmelden" zu einer echten Benutzerauthentifizierung macht, anstatt nur den Zugriff auf Benutzerdaten zu autorisieren.

Wichtige OIDC-Konzepte:

• ID Token: ein JWT für den Client, um zu überprüfen, wer der Benutzer ist – niemals an APIs senden
• Access Token: zum Aufrufen von Resource-Server-APIs – der Client sollte es als opak behandeln
• UserInfo-Endpunkt: ein API-Endpunkt, der Benutzerangaben zurückgibt, wenn er mit dem Access Token aufgerufen wird
• nonce: ein in der Autorisierungsanfrage enthaltener Zufallswert, der im ID Token überprüft wird, um Replay-Angriffe zu verhindern

Häufige Schwachstellen und Angriffe

Offene Weiterleitung über redirect_uri

Wenn der Authorization Server die redirect_uri nicht streng überprüft, kann ein Angreifer sie ändern, um auf seinen eigenen Server zu zeigen, und den Autorisierungscode stehlen, wenn das Opfer autorisiert. Verteidigung: Registrieren Sie exakte Weiterleitungs-URIs; verbieten Sie Wildcard- oder Musterabgleich.

State-Parameter CSRF

Das Weglassen oder Nicht-Validieren des state-Parameters ermöglicht es einem Angreifer, den Browser eines Opfers dazu zu bringen, einen Autorisierungsflow abzuschließen, den der Angreifer initiiert hat, und möglicherweise das Konto des Opfers mit der Identität des Angreifers zu verknüpfen. Verteidigung: Generieren Sie immer einen kryptografisch zufälligen state und validieren Sie ihn bei der Rückkehr.

Token-Leakage über Referer

Der Implicit Flow (jetzt veraltet) gab Token direkt im URL-Fragment zurück, was über Referer-Header oder den Browser-Verlauf durchsickern konnte. Verteidigung: Verwenden Sie niemals den Implicit Flow – verwenden Sie stattdessen Authorization Code + PKCE.

JWT-Verwechslungsangriffe

JWTs sind eigenständig und müssen sorgfältig validiert werden. Häufige Fehler:

• alg: none akzeptieren – deaktivieren Sie Algorithmusverhandlung, geben Sie immer erlaubte Algorithmen explizit an
• Den öffentlichen RS256-Schlüssel als HS256-Geheimnis verwenden – fixieren Sie den erwarteten Algorithmus serverseitig
• iss-, aud- und exp-Angaben nicht validieren

Unzureichende Scope-Validierung

Access Tokens sollten auf die minimal erforderlichen Berechtigungen beschränkt sein. APIs müssen überprüfen, ob das präsentierte Token den erforderlichen Scope für jede Operation hat – nehmen Sie nicht an, dass ein gültiges Token vollständigen Zugriff bedeutet.

Sichere Implementierungs-Checkliste

• Verwenden Sie Authorization Code + PKCE für alle Clients
• Registrieren Sie exakte, nur-HTTPS-Weiterleitungs-URIs
• Validieren Sie immer den state-Parameter (oder verwenden Sie PKCE, das gleichwertigen Schutz bietet)
• Validieren Sie alle JWT-Angaben: iss, aud, exp, nbf, Algorithmus
• Speichern Sie Token im Speicher (nicht in localStorage) in SPAs – verwenden Sie HttpOnly-Cookies für Refresh-Token in Web-Apps
• Implementieren Sie Token-Rotation: stellen Sie bei jeder Verwendung ein neues Refresh-Token aus und invalidieren Sie das alte
• Verwenden Sie kurzlebige Access Tokens (5–15 Minuten) mit Refresh-Tokens für Sitzungskontinuität
• Prüfen Sie regelmäßig alle OAuth-Anwendungen, die Zugriff auf Ihren Authorization Server haben
• Protokollieren oder exponieren Sie Access Tokens niemals in URLs, Protokollen oder Fehlermeldungen