Was macht OAuth-Providern?
Regeln
- Verwenden Sie den Authorization Code Flow mit PKCE für öffentliche Clients (SPAs, mobil) – niemals den Implicit Flow
- Serverseitiger Code-Austausch für Web-Apps – das Client-Secret verlässt niemals den Server
- State-Parameter: Zufälligen
state generieren, in Session/Cookie speichern, beim Callback überprüfen – verhindert CSRF
- Google OAuth: Bereiche
openid email profile, id_token für Benutzerinformationen verwenden
- GitHub OAuth: Bereich
read:user user:email, Code austauschen unter https://github.com/login/oauth/access_token
- Discord OAuth: Bereich
identify email, Token-Endpunkt unter https://discord.com/api/oauth2/token
- Token-Aktualisierung:
refresh_token serverseitig speichern, vor Ablauf von access_token aktualisieren
- Sitzungsverwaltung: App-Sitzung bei erfolgreichem OAuth-Callback erstellen, OAuth-Tokens nicht in Cookies speichern
- Konten verknüpfen: Benutzern erlauben, mehrere Anbieter mit einem Konto über die
accounts-Tabelle zu verbinden
Muster
export async function GET(req: Request) {
const { searchParams } = new URL(req.url);
const code = searchParams.get("code");
const state = searchParams.get("state");
if (state !== cookies().get("oauth_state")?.value) {
return new Response("Ungültiger state", { status: 400 });
}
const tokens = await exchangeCodeForTokens(code);
const userInfo = await fetchUserInfo(tokens.access_token);
const user = await upsertUser(userInfo);
await createSession(user.id);
return redirect("/dashboard");
}
Zu vermeiden
- Client-Secrets im Frontend-Code speichern – Tokens immer serverseitig austauschen
- Den
state-Parameter überspringen – CSRF-Angriffe sind real
- Rohe OAuth-Tokens in Cookies speichern – verwenden Sie serverseitige Sitzungen
- Vergessen, den Fall "Benutzer existiert bereits mit dieser E-Mail" beim Verknüpfen von Anbietern zu behandeln