Supabase Auth in der Praxis: E-Mail-Verifizierung, OAuth und Session-Management

Sie öffnen das Supabase Dashboard, klicken auf Authentication – und stehen vor einer Flut an Optionen. E-Mail-Verifizierung, Magic Link, OAuth, SSR-Konfiguration … Welche Methode passt? Wie richtet man sie ein?

Wenn Ihnen das bekannt vorkommt: Keine Sorge. Beim Login für ein kleines Projekt habe ich selbst einen halben Tag gebraucht, bis klar wurde, dass jede Auth-Methode ihren Einsatzbereich hat. Dieser Artikel führt die drei Kernwege von Supabase Auth zusammen: E-Mail-Verifizierung, OAuth-Integration und Session-Management – der Teil, der viele beschäftigt. Nach dem Lesen sollten Sie in etwa einer halben Stunde ein vollständiges Auth-System aufsetzen können.

E-Mail-Verifizierung – die grundlegende Auth-Methode

Ehrlich gesagt ist E-Mail-Verifizierung der einfachste, aber am leichtesten übersehene Teil von Supabase Auth.

Im Dashboard unter Authentication → Providers → Email finden Sie den Schalter „Confirm Email“. Er legt fest, ob Nutzer nach der Registrierung ihre E-Mail bestätigen müssen, bevor sie sich anmelden können. Bei gehosteten Projekten ist er standardmäßig aktiv: Nach der Registrierung erhalten Nutzer eine Bestätigungs-E-Mail und aktivieren das Konto per Link.

Bei meiner ersten Konfiguration habe ich ihn versehentlich deaktiviert. Ergebnis: Jede beliebige E-Mail-Adresse reichte zum Login, Spam-Accounts häuften sich. Seitdem weiß ich: In Produktion muss dieser Schalter an sein.

Der Code ist unkompliziert:

// E-Mail-Verifizierung bei der Registrierung auslösen
const { data, error } = await supabase.auth.signUp({
  email: '[email protected]',
  password: 'secure-password',
  options: {
    emailRedirectTo: 'https://yourapp.com/auth/callback'
  }
})

Ein wichtiges Detail: der Parameter emailRedirectTo. Nach dem Klick auf den Link in der E-Mail leitet Supabase dorthin weiter – z. B. auf die Startseite oder eine Willkommensseite.

Zu E-Mail-Vorlagen: Supabase bringt Templates für Bestätigung, Passwort-Reset und Magic Link mit. Sie bearbeiten sie unter Email Templates im Dashboard. Eigenes SMTP (Resend, SendGrid) konfigurieren Sie über Auth Hooks – für den Einstieg reichen die Standard-Templates.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Ein häufiger Stolperstein: Lokal kann die E-Mail-Verifizierung hängen bleiben, weil die lokale Supabase-Instanz keine echten E-Mails versendet. Mit Mailcatcher Test-Mails ansehen – oder Confirm Email lokal vorübergehend deaktivieren und vor dem Go-live wieder aktivieren.

OAuth-Integration – Ein-Klick-Login

OAuth-Login verbessert die User Experience deutlich. Kein Passwort merken, ein Klick auf GitHub oder Google – die Conversion liegt oft über der klassischen E-Mail-Registrierung.

Supabase unterstützt viele OAuth Provider: GitHub, Google, Facebook, Apple, Azure, Twitter, Discord – insgesamt 15+. Am häufigsten nutze ich GitHub und Google; deren Setup ist am klarsten dokumentiert.

Für GitHub OAuth legen Sie zuerst eine OAuth App an (Settings → Developer settings → OAuth Apps → New OAuth App). Entscheidend ist die Callback URL:

https://<Ihr-Projekt-ref>.supabase.co/auth/v1/callback

Lokal verwenden Sie:

http://localhost:54321/auth/v1/callback

Client ID und Client Secret kopieren Sie ins Supabase Dashboard (Authentication → Providers → GitHub). Der Client-Aufruf ist dann simpel:

// GitHub OAuth Login
const { data, error } = await supabase.auth.signInWithOAuth({
  provider: 'github',
  options: {
    redirectTo: 'https://yourapp.com/auth/callback'
  }
})

Google OAuth folgt einem ähnlichen Ablauf, unterscheidet sich aber in einem Punkt: Google verlangt separate Client IDs für Web, iOS und Android. Unterstützen Sie Web und Mobile parallel, konfigurieren Sie beide.

Nach OAuth-Login liefert Supabase einen Provider Token. Damit rufen Sie APIs des Drittanbieters auf – z. B. GitHub-Repositories oder Google Drive. Praktisch, wenn Ihre App externe Dienste einbindet.

Typischer Fehler in der lokalen Entwicklung: falsche Callback URL. Ich hatte einmal Port 3000 (Frontend) statt 54321 (Supabase) eingetragen – Login endete mit Fehlerseite. Callback zeigt auf den Supabase-Port, nicht auf den Frontend-Port.

Session-Management – JWT und PKCE-Flow

Dieses Kapitel verwirrt am Anfang oft. Wie hängen JWT, Refresh Token und PKCE zusammen?

Eine Supabase-Session besteht aus zwei Teilen: Access Token (kurzlebiges JWT) und Refresh Token (langlebig). Der Access Token ist standardmäßig 1 Stunde gültig; offiziell mindestens 5 Minuten empfohlen – wegen Clock Skew. Der Refresh Token ist einmalig nutzbar und tauscht einen neuen Access Token ein.

Wichtiges Detail: Refresh Token haben ein 10-Sekunden-Wiederverwendungsfenster. In SSR-Umgebungen dürfen mehrere gleichzeitige Refresh-Anfragen innerhalb von 10 Sekunden erfolgen, ohne die Session zu beenden – sinnvoll, wenn Frontend und Backend parallel die Session bearbeiten.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

PKCE: Mit Next.js oder anderen SSR-Frameworks ist PKCE Pflicht. Der Implicit Flow legt Tokens in der URL offen – in SSR unsicher. PKCE schützt den Austausch über einen Code Verifier.

PKCE erfordert zwei Parameter bei der Client-Initialisierung:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY, {
  auth: {
    detectSessionInUrl: true,
    flowType: 'pkce'
  }
})

Zusätzlich brauchen Sie eine Callback-Route für den Code-Austausch:

// Next.js App Router - app/auth/callback/route.ts
import { NextResponse } from 'next/server'
import { createClient } from '@/utils/supabase/server'

export async function GET(request: Request) {
  const { searchParams, origin } = new URL(request.url)
  const code = searchParams.get('code')

  if (code) {
    const supabase = await createClient()
    const { error } = await supabase.auth.exchangeCodeForSession(code)
    if (!error) {
      return NextResponse.redirect(`${origin}/dashboard`)
    }
  }
  return NextResponse.redirect(`${origin}/auth/error`)
}

Der Auth Code gilt 5 Minuten und ist nur einmal einlösbar. Schlägt der Austausch fehl, liegt es meist an Timeout oder doppelter Verwendung.

Supabase bietet drei Session-Limit-Modi: Time-boxed (feste Laufzeit, dann Abmeldung), Inactivity Timeout (Abmeldung bei Inaktivität) und Single Session per User (nur eine aktive Session pro Konto). Relevant für SOC 2- oder HIPAA-konforme Anwendungen.

Praxis-Tipps und häufige Fragen

Welche Auth-Methode passt?

Kurz: E-Mail-Verifizierung für Registrierung mit vollständigen Nutzerdaten; OAuth für schnellen Login (Developer Tools, B2B); Magic Link für passwortlose Szenarien (temporärer Zugriff, Mobile-first).

Vergleich der drei Methoden:

Checkliste für Next.js und andere SSR-Frameworks:

1. detectSessionInUrl: true – Session automatisch aus URL extrahieren
2. flowType: 'pkce' – PKCE erzwingen
3. redirectTo korrekt – Callback-Route muss Auth Code verarbeiten
4. Umgebungsvariablen – NEXT_PUBLIC_SUPABASE_URL und NEXT_PUBLIC_SUPABASE_ANON_KEY gesetzt

Häufige Fragen:

F: Warum schlägt OAuth lokal fehl?

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Meist falsche Callback URL. Im Supabase Dashboard unter Provider prüfen: localhost-Adresse, nicht die Produktions-Domain.

F: Werden Nutzer nach JWT-Ablauf abgemeldet?

Der Client sollte automatisch refreshen. Der onAuthStateChange-Listener von Supabase übernimmt das – manuelles Refresh ist nicht nötig.

F: Session verschwindet plötzlich?

In SSR häufig. Server Client und Browser Client korrekt initialisiert? Werden Cookies zuverlässig weitergegeben?

Fazit

Die drei Auth-Wege von Supabase ergänzen sich: E-Mail-Verifizierung als Basis für formelle Registrierung, OAuth für schnellen Login, Session-Management als Fundament – JWT und PKCE müssen in SSR-Umgebungen sitzen.

Die typischen Fallstricke sind simpel: Callback URL falsch, Confirm Email vergessen, PKCE nicht konfiguriert. Diese Details klären, und Ihr Auth-System läuft stabil.

Nächster Schritt: Nach der Auth-Konfiguration Row Level Security (RLS) für Ihre Daten aktivieren. RLS und Auth sind eng verzahnt – jeder Nutzer sieht nur eigene Daten. Das schließt den Kreis für ein vollständiges Auth-System.