OAuth2-Authentifizierung: Sichere Implementierung
OAuth2 ist ein Authorization-Framework, das es Anwendungen ermöglicht, begrenzten Zugriff auf Benutzer-Ressourcen zu erhalten, ohne Benutzer-Passwörter preiszugeben. OAuth2 ist der Standard für API-Authentifizierung und wird von Google, Facebook, GitHub, und vielen anderen Services verwendet. Das Verständnis von OAuth2-Flows, Token-Management, und Sicherheits-Best-Practices ist essentiell für moderne Web- und API-Entwicklung.
Das Hauptproblem, das OAuth2 löst, ist die sichere Delegation von Zugriff. Statt dass eine Anwendung Benutzer-Passwörter speichert (was ein Sicherheitsrisiko ist), kann eine Anwendung OAuth2 verwenden, um Zugriff zu erhalten, ohne Passwörter zu kennen. Der Benutzer authentifiziert sich beim Authorization Server (z.B. Google), und die Anwendung erhält einen Token, der begrenzten Zugriff gewährt.
OAuth2 definiert verschiedene Flows für verschiedene Anwendungs-Typen: Authorization Code Flow für Web-Anwendungen, Implicit Flow (veraltet), Client Credentials Flow für Server-zu-Server-Kommunikation, und Resource Owner Password Credentials Flow (nicht empfohlen). Der Authorization Code Flow ist der häufigste und sicherste Flow für Web-Anwendungen.
OAuth2-Komponenten
Resource Owner:
Der Resource Owner ist der Benutzer, der Zugriff auf Ressourcen gewährt. In den meisten Fällen ist dies der Endbenutzer, der sich bei einer Anwendung anmeldet.
Client:
Der Client ist die Anwendung, die Zugriff auf Ressourcen anfordert. Dies kann eine Web-Anwendung, Mobile-App, oder Server-Anwendung sein.
Authorization Server:
Der Authorization Server authentifiziert den Resource Owner und gibt Authorization Codes und Tokens aus. Beispiele sind Google OAuth, GitHub OAuth, oder ein eigener Authorization Server.
Resource Server:
Der Resource Server hostet geschützte Ressourcen und akzeptiert Access Tokens für Zugriff. Dies ist typischerweise eine API, die Daten zurückgibt, wenn ein gültiger Token präsentiert wird.
Authorization Code Flow
Der Authorization Code Flow ist der häufigste und sicherste Flow für Web-Anwendungen. Der Flow besteht aus mehreren Schritten:
1. Authorization Request: Der Client leitet den Benutzer zum Authorization Server um, mit Client-ID, Redirect-URI, Scope, und State-Parameter.
2. User Authorization: Der Benutzer authentifiziert sich beim Authorization Server und gewährt oder verweigert Zugriff.
3. Authorization Code: Wenn der Benutzer Zugriff gewährt, leitet der Authorization Server zum Client um mit einem Authorization Code.
4. Token Exchange: Der Client tauscht den Authorization Code gegen Access Token und Refresh Token (mit Client-Secret).
5. Resource Access: Der Client verwendet den Access Token, um auf geschützte Ressourcen zuzugreifen.
Der Authorization Code Flow ist sicher, weil der Authorization Code nur kurzlebig ist und gegen einen Token getauscht werden muss, was Client-Secret erfordert. Der Access Token wird nie im Browser exponiert.
Access Tokens und Refresh Tokens
Access Tokens:
Access Tokens sind kurzlebig (typischerweise 1 Stunde) und gewähren Zugriff auf geschützte Ressourcen. Sie werden im Authorization Header mitgesendet: Authorization: Bearer <token>. Access Tokens sollten sicher gespeichert werden und nie in URLs oder Logs exponiert werden.
Refresh Tokens:
Refresh Tokens sind langlebig und werden verwendet, um neue Access Tokens zu erhalten, wenn Access Tokens ablaufen. Refresh Tokens sollten noch sicherer gespeichert werden als Access Tokens, weil sie langlebig sind. Wenn ein Refresh Token kompromittiert wird, kann ein Angreifer kontinuierlich neue Access Tokens erhalten.
Token-Format:
OAuth2 spezifiziert nicht das Token-Format, aber JWT (JSON Web Tokens) ist häufig. JWT-Tokens sind selbstbeschreibend und enthalten Claims (Informationen über den Benutzer, Scopes, Expiration, etc.). JWT-Tokens können verifiziert werden, ohne den Authorization Server zu kontaktieren.
Scopes und Permissions
Scopes definieren, welche Berechtigungen eine Anwendung anfordert. Beispiele: read:user für Lese-Zugriff auf Benutzer-Daten, write:posts für Schreib-Zugriff auf Posts. Scopes sollten minimal sein - nur die Berechtigungen anfordern, die tatsächlich benötigt werden.
Der Benutzer sieht die angeforderten Scopes während der Authorization und kann entscheiden, ob er Zugriff gewährt. Dies gibt dem Benutzer Kontrolle über seine Daten.
Sicherheits-Best-Practices
State-Parameter:
Der State-Parameter sollte verwendet werden, um CSRF-Angriffe zu verhindern. Ein zufälliger State-Wert wird in der Authorization Request gesendet und sollte in der Redirect-Response zurückkommen. Wenn der State-Wert nicht übereinstimmt, sollte die Authorization abgelehnt werden.
HTTPS:
OAuth2 sollte immer über HTTPS verwendet werden. Tokens und Authorization Codes werden über das Netzwerk übertragen und müssen verschlüsselt sein.
Client-Secret:
Client-Secret sollte sicher gespeichert werden und nie im Client-Code (Browser, Mobile-App) exponiert werden. Für Public Clients (Single-Page-Apps, Mobile-Apps) sollte PKCE (Proof Key for Code Exchange) verwendet werden.
Token-Storage:
Access Tokens sollten sicher gespeichert werden. In Web-Anwendungen sollten sie in HttpOnly Cookies oder Memory gespeichert werden, nicht in LocalStorage (wegen XSS-Risiko).
Token-Expiration:
Access Tokens sollten kurzlebig sein (1 Stunde oder weniger). Refresh Tokens sollten verwendet werden, um neue Access Tokens zu erhalten, wenn sie ablaufen.
Token-Revocation:
Token-Revocation sollte unterstützt werden. Wenn ein Benutzer sich abmeldet oder ein Token kompromittiert wird, sollte der Token widerrufen werden können.
PKCE für Public Clients
PKCE (Proof Key for Code Exchange) ist eine Erweiterung von OAuth2 für Public Clients (Single-Page-Apps, Mobile-Apps), die kein Client-Secret sicher speichern können. PKCE verwendet einen Code Verifier und Code Challenge, um Authorization Code Interception zu verhindern.
PKCE ist jetzt empfohlen für alle OAuth2-Implementierungen, nicht nur für Public Clients. Es fügt eine zusätzliche Sicherheitsebene hinzu.
Häufige Fehler vermeiden
Client-Secret im Client-Code:
Client-Secret sollte nie im Browser-Code oder Mobile-App-Code exponiert werden. Für Public Clients sollte PKCE verwendet werden.
Fehlender State-Parameter:
State-Parameter sollte immer verwendet werden, um CSRF-Angriffe zu verhindern.
Unsicherer Token-Storage:
Access Tokens sollten nicht in LocalStorage gespeichert werden (XSS-Risiko). HttpOnly Cookies oder Memory sind sicherer.
Zu breite Scopes:
Nur die Scopes anfordern, die tatsächlich benötigt werden. Zu breite Scopes geben mehr Zugriff als nötig.
Fehlende Token-Expiration:
Access Tokens sollten ablaufen. Refresh Tokens sollten verwendet werden, um neue Access Tokens zu erhalten.
Best Practices
Verwenden Sie Authorization Code Flow:
Authorization Code Flow ist der sicherste Flow für Web-Anwendungen. Vermeiden Sie Implicit Flow (veraltet) oder Resource Owner Password Credentials Flow.
Implementieren Sie PKCE:
PKCE sollte für alle OAuth2-Implementierungen verwendet werden, besonders für Public Clients.
Sichere Token-Storage:
Access Tokens sollten sicher gespeichert werden. HttpOnly Cookies oder Memory sind besser als LocalStorage.
Minimale Scopes:
Nur die Scopes anfordern, die tatsächlich benötigt werden. Dies gibt Benutzern mehr Kontrolle und reduziert Sicherheitsrisiken.
Token-Revocation:
Implementieren Sie Token-Revocation, damit Tokens widerrufen werden können, wenn sie kompromittiert werden.
Kommentare