Fournisseurs OAuth

Que fait Fournisseurs OAuth ?

Règles

• Utiliser le flux Authorization Code avec PKCE pour les clients publics (SPA, mobiles) — jamais le flux implicite
• Échange côté serveur pour les applications web — le secret client ne quitte jamais le serveur
• Paramètre state : générer un state aléatoire, le stocker dans la session/cookie, vérifier lors du callback — empêche les attaques CSRF
• OAuth Google : scopes openid email profile, utiliser id_token pour les informations utilisateur
• OAuth GitHub : scope read:user user:email, échanger le code à https://github.com/login/oauth/access_token
• OAuth Discord : scope identify email, point de terminaison de token à https://discord.com/api/oauth2/token
• Rafraîchissement du token : stocker refresh_token côté serveur, rafraîchir avant l'expiration de access_token
• Gestion de session : créer une session applicative lors d'un callback OAuth réussi, ne pas stocker les tokens OAuth dans les cookies
• Lier les comptes : permettre aux utilisateurs de connecter plusieurs fournisseurs à un seul compte via la table accounts

Modèles

// Gestionnaire de callback OAuth
export async function GET(req: Request) {
  const { searchParams } = new URL(req.url);
  const code = searchParams.get("code");
  const state = searchParams.get("state");

  // Vérifier que state correspond à la valeur stockée
  if (state !== cookies().get("oauth_state")?.value) {
    return new Response("État invalide", { status: 400 });
  }

  // Échanger le code contre des tokens
  const tokens = await exchangeCodeForTokens(code);
  const userInfo = await fetchUserInfo(tokens.access_token);

  // Créer ou lier le compte, créer la session
  const user = await upsertUser(userInfo);
  await createSession(user.id);

  return redirect("/dashboard");
}

À éviter

• Stocker les secrets client dans le code frontend — toujours échanger les tokens côté serveur
• Sauter le paramètre state — les attaques CSRF sont réelles
• Stocker les tokens OAuth bruts dans les cookies — utiliser des sessions côté serveur
• Oublier de gérer le cas « l'utilisateur existe déjà avec cet email » lors de la liaison des fournisseurs