OAuth
Définition
Protocole standard qui permet à votre application d'authentifier un utilisateur via un fournisseur tiers (Google, GitHub, LinkedIn) sans manipuler ses identifiants.
Comment ça marche
OAuth 2.0 est le protocole standard pour déléguer l'authentification et l'autorisation à un fournisseur tiers. Le flow classique : l'utilisateur clique sur "Continuer avec Google", il est redirigé vers Google qui affiche les permissions demandées, il valide, Google renvoie l'utilisateur sur votre site avec un code d'autorisation. Votre serveur échange ce code contre un access token et un refresh token via une API privée. Vous récupérez ensuite le profil (email, nom, avatar) avec ce token, vous créez ou mettez à jour l'utilisateur dans votre base, et vous le connectez. Toute l'opération prend 2-3 secondes côté utilisateur.
À quoi ça sert
OAuth résout deux problèmes simultanément. La friction d'inscription : taper un email, choisir un mot de passe, valider un email, c'est plusieurs étapes qui font perdre 30 à 40% des inscriptions. "Continuer avec Google" prend 5 secondes. La sécurité : vous ne stockez plus de mot de passe, donc plus de logique "mot de passe oublié", plus de risque de fuite massive, plus de mises à jour de hashing à suivre. Pour un SaaS B2B, proposer Google + Microsoft couvre 95% des cas et améliore mesurablement le taux de conversion. Pour un produit B2C, on ajoute Apple (obligatoire sur iOS), Facebook ou Twitter selon l'audience.
Les providers à choisir
Pour un SaaS B2B, Google Workspace et Microsoft 365 couvrent 90% du marché professionnel : on propose les deux. GitHub est attendu sur les SaaS dev (CI/CD, monitoring, IaC). LinkedIn est rarement utilisé en production parce que l'API est restrictive. Pour un produit B2C en France, Apple Sign In est obligatoire sur iOS si on propose Google ou Facebook ; on l'ajoute pour respecter les guidelines Apple Store. Slack OAuth sert pour les intégrations bots, pas pour l'auth générale. Le bon défaut pour un SaaS européen : Google + Microsoft + email/password classique en fallback.
OAuth vs OpenID Connect
OAuth 2.0 est techniquement un protocole d'autorisation ("cette application peut accéder à mes contacts"), pas d'authentification ("je suis bien John"). OpenID Connect (OIDC) est une couche ajoutée par-dessus OAuth 2.0 qui standardise l'identité : à la fin du flow, vous obtenez un ID token qui certifie qui est l'utilisateur. C'est ce que Google, Microsoft, Apple utilisent par défaut. Quand on dit "OAuth" pour la connexion en 2026, on parle en pratique presque toujours d'OIDC. Les SDK modernes (Supabase Auth, Clerk, Auth.js) le gèrent transparent : tu écris une ligne, le protocole complet est géré.
Quand l'utiliser
OAuth est le bon défaut pour tout produit moderne : SaaS B2B, e-commerce, marketplace, communauté, app mobile. Le seul cas où on s'en passe : un outil interne qui doit fonctionner sans accès internet, ou un projet avec contrainte stricte de zéro dépendance externe. Sur un SaaS B2B sérieux, on combine OAuth pour l'inscription rapide avec un système de SSO SAML pour les grands comptes (voir le terme dédié). Sur du B2C, OAuth seul suffit. Sur du B2B, OAuth + email/password + SAML couvre toutes les attentes.
Les outils
Supabase Auth gère OAuth (Google, GitHub, Apple, Microsoft, Discord, etc.) en quelques lignes de config dans le dashboard. Clerk va plus loin avec une UI prête à l'emploi, des callbacks magnifiques, mais c'est payant à partir d'un certain volume. Auth.js (anciennement NextAuth) est l'open-source de référence pour Next.js : flexible, gratuit, supporte tous les providers, mais demande plus de configuration. WorkOS est l'option pour ceux qui veulent OAuth + SAML + SCIM dans une seule API. Le choix dépend du budget, de la complexité du produit, et de la confiance dans l'écosystème.
Les pièges à éviter
Ne pas valider l'email de retour : un compte Google avec email pas vérifié peut usurper un compte existant. On vérifie email_verified avant de fusionner. Stocker les refresh tokens en clair en base : on les chiffre au repos. Ne pas gérer le scope : demander trop de permissions à Google freine l'utilisateur ("cette app veut accéder à votre Drive ?"), on demande le minimum. Ne pas tester le flow d'erreur : refus de l'utilisateur, expiration du code, problème réseau côté provider, ces cas arrivent et il faut un message clair. Et ne jamais déléguer le PKCE (Proof Key for Code Exchange) sur les apps mobiles, c'est ce qui protège contre l'interception du code d'autorisation.