OAuth 2.0
OAuth 2.0 ist ein offener Standard für delegierte Autorisierung (RFC 6749). Er ermöglicht es Benutzern, einer Anwendung eingeschränkten Zugriff auf ihre Daten bei einem anderen Dienst zu gewähren – ohne Passwörter weiterzugeben. Wenn sich ein Benutzer mit Google, GitHub oder Microsoft bei einer Webapps anmeldet, läuft im Hintergrund ein OAuth-2.0-Flow.
Wie funktioniert OAuth 2.0?
OAuth 2.0 definiert vier Rollen: Resource Owner (Benutzer), Client (Anwendung), Authorization Server (z. B. Google) und Resource Server ( API ). Der Ablauf: 1. Die Anwendung leitet den Benutzer zum Authorization Server weiter. 2. Der Benutzer gibt seine Zustimmung (Consent). 3. Der Authorization Server sendet einen Authorization Code zurück. 4. Die Anwendung tauscht den Code gegen ein Access-Token (oft ein JWT ). 5. Das Access-Token wird für API-Anfragen verwendet.
OAuth 2.0 Flows im Überblick
Authorization Code Flow: Standard für serverseitige Anwendungen – der sicherste Flow. Authorization Code Flow + PKCE: Pflicht für Single-Page-Applications und mobile Apps. Client Credentials Flow: Für Server-zu-Server-Kommunikation ohne Benutzerkontext. Implicit Flow: Veraltet und unsicher – nicht mehr verwenden. Die Wahl des Flows hängt vom Anwendungstyp ab: Server-Side Rendering -Anwendungen nutzen den Authorization Code Flow, SPAs nutzen PKCE.
OAuth 2.0 vs. OpenID Connect
OAuth 2.0 regelt Autorisierung (was darf die App?), nicht Authentifizierung (wer ist der Benutzer?). OpenID Connect (OIDC) baut auf OAuth 2.0 auf und fügt eine Identitätsschicht hinzu: einen standardisierten ID-Token ( JWT ), der Informationen über den Benutzer enthält. Für Login-Funktionen (Social Login, SSO) wird immer OIDC empfohlen, nicht OAuth 2.0 allein.
Sicherheit bei OAuth-Implementierungen
PKCE für alle öffentlichen Clients (SPAs, Mobile Apps). State-Parameter gegen CSRF-Angriffe. Redirect-URIs strikt validieren – keine Wildcards. Tokens in HttpOnly-Cookies oder sicheren Stores, nie in localStorage. Scopes auf das Minimum beschränken. Client-Secrets als Secret Management verwalten, nie im Frontend-Code. Rate Limiting auf Token-Endpunkten implementieren.
Unser Ansatz
OAuth 2.0 setzen wir gezielt dort ein, wo Drittanbieter-Login erforderlich ist – etwa Google- oder GitHub-Login in Kunden-WebApps. Dafür nutzen wir django-oauth-toolkit im Django-REST-Backend mit dem Authorization Code Flow + PKCE. Client-Secrets liegen im Secret Management , Redirect-URIs sind strikt auf die Produktionsdomain beschränkt. Für rein interne Authentifizierung bevorzugen wir schlanke JWT -Flows mit Serverseitige Validierung auf jedem Endpunkt.