OAuth (Open Authorization) ist ein offenes Autorisierungsprotokoll, das es Nutzern erlaubt, Drittanwendungen begrenzten Zugriff auf ihre Ressourcen zu gewaehren, ohne Zugangsdaten direkt zu teilen. OAuth ist der Standard hinter "Mit Google anmelden", "Mit Facebook anmelden" und nahezu jeder API-Autorisierung im modernen Web.
OAuth 2.0 (der aktuelle Standard seit 2012) loest ein fundamentales Problem: Wie kann ein Nutzer einer Anwendung Zugriff auf seine Daten bei einem anderen Dienst geben, ohne sein Passwort preiszugeben? Die Antwort ist ein Token-basiertes System mit klar definierten Rollen und Ablaeufen.
Die vier Rollen in OAuth
| Rolle | Beschreibung | Beispiel |
|---|---|---|
| Resource Owner | Der Nutzer, der Zugriff gewaehrt | Website-Besucher |
| Client | Die Anwendung, die Zugriff anfordert | Eine Web-App |
| Authorization Server | Stellt Tokens aus | Google OAuth Server |
| Resource Server | Haelt die geschuetzten Daten | Google API |
OAuth 2.0 Flows
Authorization Code Flow
Der sicherste und am haeufigsten verwendete Flow fuer Server-seitige Anwendungen:
- Client leitet Nutzer zum Authorization Server weiter
- Nutzer meldet sich an und gewaehrt Zugriff
- Authorization Server leitet zurueck mit einem einmaligen Code
- Client tauscht den Code gegen ein Access Token (Server-to-Server)
- Client nutzt das Access Token fuer API-Aufrufe
Authorization Code Flow mit PKCE
Erweiterung fuer Public Clients (Single-Page Applications, Mobile Apps), bei denen kein Client Secret sicher gespeichert werden kann. PKCE (Proof Key for Code Exchange) schuetzt den Code-Austausch durch einen zusaetzlichen Verifier.
Client Credentials Flow
Fuer Machine-to-Machine-Kommunikation ohne Nutzerinteraktion. Die Anwendung authentifiziert sich direkt mit Client ID und Client Secret.
Implicit Flow (veraltet)
Frueher fuer SPAs verwendet, gibt das Token direkt in der URL zurueck. Gilt als unsicher und wird durch Authorization Code + PKCE ersetzt.
| Flow | Geeignet fuer | Sicherheit |
|---|---|---|
| Authorization Code | Server-seitige Apps | Hoch |
| Authorization Code + PKCE | SPAs, Mobile Apps | Hoch |
| Client Credentials | Server-to-Server | Hoch |
| Implicit | Niedrig |
Tokens in OAuth
Access Token
Das Access Token ist der "Schluessel", mit dem die Anwendung auf geschuetzte Ressourcen zugreift. Es hat eine begrenzte Lebensdauer (typisch: 1 Stunde) und wird bei jedem API-Aufruf im Authorization-Header mitgesendet.
Access Tokens koennen als undurchsichtige Strings oder als JWT (JSON Web Token) implementiert sein.
Refresh Token
Das Refresh Token ermoeglicht es, ein neues Access Token zu erhalten, ohne den Nutzer erneut zur Anmeldung aufzufordern. Refresh Tokens haben eine laengere Lebensdauer und muessen sicher gespeichert werden.
Scopes
Scopes definieren den Umfang des Zugriffs. Statt Vollzugriff kann die Anwendung nur bestimmte Berechtigungen anfordern:
read:profile— Profilinformationen lesenwrite:posts— Beitraege erstellenread:email— E-Mail-Adresse lesen
OAuth in der Webentwicklung
Social Login implementieren
Fuer Webdesign-Projekte ist Social Login (Google, Facebook, Apple, GitHub) eine haeufige Anforderung. OAuth 2.0 + OpenID Connect ist der Standard dafuer.
In Next.js-Projekten bieten Libraries wie NextAuth.js (Auth.js) eine fertige Implementierung mit Unterstuetzung fuer Dutzende OAuth-Provider.
API-Integrationen
Viele Third-Party-Services nutzen OAuth fuer den API-Zugriff:
- Google APIs: Analytics, Search Console, YouTube
- Social Media APIs: Instagram, LinkedIn, TikTok
- Payment: Stripe Connect
- CRM: HubSpot, Salesforce
Best Practices
- PKCE immer verwenden: Auch bei Server-seitigen Anwendungen empfohlen
- State-Parameter nutzen: Schuetzt vor CSRF-Angriffen
- Redirect-URIs einschraenken: Nur exakte URIs erlauben, keine Wildcards
- Tokens sicher speichern: Access Tokens im Speicher, Refresh Tokens in HttpOnly Cookies
- Minimale Scopes anfordern: Nur die Berechtigungen, die tatsaechlich benoetigt werden
OAuth und Datenschutz
OAuth ist auch aus DSGVO-Perspektive relevant. Wenn ein Nutzer "Mit Google anmelden" verwendet, werden personenbezogene Daten (Name, E-Mail) vom Identity Provider an die Anwendung uebermittelt. Die Anwendung muss:
- Transparent informieren, welche Daten uebermittelt werden
- Eine Rechtsgrundlage fuer die Verarbeitung haben
- Nur die minimal noetigen Scopes anfordern
- Dem Nutzer die Moeglichkeit geben, die Verknuepfung aufzuheben
OAuth ist ein maaechtiges Werkzeug fuer sichere, passwortlose Autorisierung — aber seine korrekte Implementierung erfordert sorgfaeltige Beachtung der Sicherheits- und Datenschutzanforderungen.