Als Freelancerin habe ich oft OAuth-Logins (Google, GitHub) in Projekte eingebaut — für Kundenseiten, interne Tools oder MVPs. Dabei ist mir eines wichtig: Nutzer müssen sich bequem anmelden können, aber niemals auf Kosten ihrer Daten oder Sicherheit. In diesem Artikel teile ich aus meiner Praxis: wie OAuth funktioniert, welche Fallstricke es gibt und wie du Google- und GitHub-Logins sicher implementierst, ohne Userdaten zu gefährden.

Was OAuth wirklich ist — kurz und pragmatisch

OAuth ist kein Login-Protokoll per se, sondern ein Autorisierungsframework. Bei "Social Logins" kommt häufig OpenID Connect (OIDC) obendrauf — das liefert ID-Tokens (JWT) zur Authentifizierung. Wichtig zu verstehen: OAuth erlaubt, dass eine Anwendung Zugriff auf Ressourcen (z. B. E-Mails, Repositories) einer anderen Anwendung bekommt, während OIDC bestätigt, wer der Nutzer ist.

Welche Flows sollte ich als Freelancer verwenden?

Die Wahl des Flows hängt vom App-Typ ab. Hier eine kompakte Übersicht:

App-Typ Empfohlener Flow Warum
Server-seitige Webapp Authorization Code Flow Keep tokens auf dem Server, sicherer; unterstützt Refresh Tokens
Single Page App (SPA) Authorization Code Flow + PKCE Vermeidet unsichere Implicit Flow, PKCE schützt vor Code-Interception
Native Mobile App Authorization Code Flow + PKCE Best practice für mobile Clients

Sicherheitsprinzipien, die ich nie ignoriere

  • Minimalprinzip bei Scopes: Fordere nur die Scopes an, die du wirklich brauchst. Nutzervertrauen steigt, Risiko sinkt.
  • State-Parameter: Nutze den state bei jeder Auth-Anfrage, um CSRF-Angriffe zu verhindern. Prüfe serverseitig, ob state übereinstimmt.
  • PKCE überall dort, wo es möglich ist: Für SPAs und mobile Apps schützt PKCE gegen Code-Diebstahl.
  • ID-Token-Validierung: Prüfe Signature, Audience (aud), Issuer (iss) und Ablauf (exp).
  • HTTPS zwingend: Keine Ausnahmen — alle Redirect-URIs und API-Endpunkte müssen TLS verwenden.
  • Secrets sicher lagern: Client-Secret nicht im Frontend; verwahre es in Umgebungsvariablen oder einem Secret-Manager.
  • Cookie-Härtung: Verwende HttpOnly, Secure und SameSite=strict/ Lax je nach Use-Case.

Praktische Umsetzung: Google und GitHub im Vergleich

Beide Anbieter haben solide Dokumentationen, aber es gibt Unterschiede in Details und Scope-Namen.

  • Google: OIDC out-of-the-box, liefert email_verified, name, picture. Scopes wie openid profile email.
  • GitHub: OAuth2 mit optionalem OIDC-ähnlichem Verhalten via API (für Benutzerprofil musst du read:user oder user:email anfragen).

Ich empfehle für beide Anbieter: erst nur openid email (Google) bzw. nur Zugriff auf öffentliches Profil & E-Mail (GitHub), und erst erweitern, wenn eine Funktion es verlangt.

Tokenmanagement — wo viele Fehler entstehen

Token sind die Schlüssel. Der sichere Umgang entscheidet über die Sicherheit der ganzen Anwendung.

  • Keine Tokens im localStorage (SPA): localStorage ist anfällig für XSS. Bevorzuge serverseitige Sessions oder https-only Cookies mit HttpOnly.
  • Refresh Tokens: Nur Server-seitig aufbewahren. Google erlaubt in vielen Fällen Refresh Tokens; GitHub ebenfalls (wenn du offline access brauchst).
  • Token-Rotation: Implementiere Rotation, wenn möglich — das limitiert die Lebensdauer kompromittierter Tokens.
  • Revoke und Logout: Biete Nutzer:innen einen echten Logout: lösche Session auf deinem Server und rufe, wenn möglich, die Revoke-API des Anbieters auf.

Backend-Checks, die ich immer mache

Die Erstanmeldung ist nur der Anfang. Ich habe eine Checkliste für die Server-Seite, die ich bei jeder Integration durchgehe:

  • Validiere ID-Token (Signatur, aud, iss, exp).
  • Prüfe state-Parameter gegen gespeicherte Werte.
  • Nutze HTTPS-only Callback-URLs, keine generischen Wildcards.
  • Speichere nur notwendige User-Attribute (z. B. E-Mail, Name, Provider-ID), niemals vollständige Tokens als Plaintext in DB.
  • Setze ein Monitoring für ungewöhnliche Login-Muster (mehrere IPs, viele fehlgeschlagene Versuche).

Implementierungs-Tipps je Technologie-Stack

Je nach Tech-Stack nutze ich verschiedene Bibliotheken — aber die Konzepte bleiben gleich:

  • Node.js / Express: passport.js (für schnelles Prototyping), oder openid-client für OIDC-Strictness. Speichere Sessions in einer Redis-Session-Store für Skalierung.
  • Next.js / Vercel: NextAuth.js ist praktisch, bietet viele Provider vorgefertigt. Achte aber auf die Konfiguration von cookies und session-token-storage.
  • Python / Django: Social-auth-app-django oder mozilla-django-oidc. Schütze CSRF und sichere deine Redirect-URLs in settings.
  • Static Frontend + Serverless Backend: Verwende PKCE im Frontend und tausche Code serverseitig gegen Tokens. Secrets in Cloud Secret Managers (AWS Secrets Manager, GCP Secret Manager).

Fehler, die ich selbst gemacht habe (und wie du sie vermeidest)

  • Too many scopes zu Beginn: Ergebnis: Nutzerrektionen und größere Angriffsfläche. Fix: Scope-Reduktion und Feature-gesteuerte Erweiterung.
  • Client-Secret im Repository: Schlimmster Anfängerfehler. Fix: Secrets in Environment-Variablen, niemals commiten.
  • Keine ID-Token-Validierung: Ich habe anfänglich nur auf Provider-Antworten vertraut. Fix: Signatur und Claims prüfen, jwks endpoint nutzen.
  • Tokens im Frontend gespeichert: Vermeide localStorage; setze auf Server-Sessions oder Secure HttpOnly Cookies.

Operational: Tests, Deploy und Rechtliches

Ich teste OAuth-Flows stets in Staging und mit mehreren Accounts (inkl. Zweitlogin). Zusätzlich beachte ich:

  • Automatisierte Tests für Token-Validierung und state-Handling.
  • Rate-Limiting, um Missbrauch zu begrenzen.
  • Logging sensibel gestalten: keine Tokens oder vollständigen Userdaten in Logs schreiben.
  • Datenschutz (DSGVO): dokumentiere, welche Daten du speicherst, stelle Löschfunktionen bereit und biete eine Datenschutzerklärung mit OAuth-spezifischen Details.

Quick-Checkliste vor dem Go-Live

  • Nur benötigte Scopes angefragt
  • Redirect-URIs fest konfiguriert, keine Wildcards
  • State und PKCE korrekt implementiert
  • Tokens sicher gespeichert (Server/HttpOnly-Cookies)
  • ID-Token-Claims validiert
  • Secrets nicht im Code
  • HTTPS überall
  • Abmeldemechanismus + Token-Revocation implementiert
  • Monitoring und Logging ohne Sensible Daten

Wenn du möchtest, kann ich dir für dein konkretes Projekt einen kurzen Review-Guide schreiben: welche Redirect-URIs zu konfigurieren sind, welche Scopes Sinn machen und welche Bibliothek ich für deinen Stack empfehlen würde. Sag mir kurz, welche Technologie du einsetzt (z. B. Next.js, Express, Django, React- SPA) — dann mache ich dir konkrete Vorschläge und Beispielkonfigurationen.