Supabase Auth : 4 méthodes de connexion, une base Postgres et zéro serveur d'auth à maintenir
L'authentification, c'est le mur que la plupart des projets rencontrent en premier. Gestion des sessions, hachage des mots de passe, OAuth, réinitialisation, jetons qui expirent : chaque brique mal posée devient une faille. Supabase Auth règle ce chantier en quelques lignes, avec Postgres et la Row Level Security derrière, et c'est la brique d'identité que nous déployons sur nos applications Next.js, dont Wiloq, notre SaaS de vestiaire numérique en production.
Dans cet article, vous allez découvrir :
- •Les 4 méthodes d'authentification (email, magic link, OAuth, OTP), quand choisir chacune et quel fournisseur SMS brancher pour vos codes
- •Comment Supabase Auth se connecte à votre base Postgres et sécurise chaque requête via la RLS
- •Ce qui se passe vraiment avec le JWT et le refresh token, et comment gérer les rôles sans usine à gaz
- •L'intégration côté Next.js et React, du client au middleware, telle qu'on la déploie chez ONDEV
- •La checklist en 8 points que nous passons avant chaque mise en production, et le match face à Auth0 et Firebase Auth
Sur Wiloq, toute l'authentification (inscription, connexion, rôles organisateur et agent) tourne sur Supabase Auth, sans aucun serveur d'auth à maintenir.
Supabase Auth : qu'est-ce que c'est vraiment ?
Supabase Auth est le service d'identité intégré à Supabase. Il gère l'inscription, la connexion, les sessions et l'émission des tokens JWT, sans que vous ayez à écrire la moindre logique de hachage ou de gestion de session.
Concrètement, chaque utilisateur qui s'inscrit atterrit dans une table auth.users, gérée par Supabase. Vous n'y touchez pas directement : vous discutez avec elle via le SDK ou l'API.
La force du système, c'est qu'il ne vit pas à côté de votre base. Il vit dedans. L'identifiant de l'utilisateur connecté est disponible dans chaque requête SQL, ce qui ouvre la porte à une sécurité native que peu de solutions offrent aussi simplement.
Pour comprendre l'écosystème complet dans lequel s'inscrit ce service, consultez notre guide complet sur Supabase : il pose les bases (base de données, API, stockage, edge functions) avant de plonger dans l'authentification.
Supabase Auth face à Auth0 et Firebase Auth
La question revient à chaque cadrage : pourquoi ne pas prendre un service d'identité dédié ? Voici la grille que nous utilisons.
| Critère | Supabase Auth | Auth0 | Firebase Auth |
|---|---|---|---|
| Lien avec la base de données | Natif : auth.uid() disponible dans chaque requête SQL et dans la RLS | Aucun, à câbler soi-même | Natif avec Firestore, via les règles de sécurité |
| Base de données | PostgreSQL standard, exportable | Indépendant de la base | Firestore, NoSQL propriétaire |
| Modèle de prix | Inclus dans le plan Supabase, facturé par utilisateur actif mensuel au-delà du quota | Par utilisateur actif, avec des paliers qui montent vite | Gratuit jusqu'à un seuil, SMS facturés à l'unité |
| Fonctions avancées (SSO entreprise, organisations) | SSO SAML sur les plans payants, multi-tenant à construire côté base | Point fort : organisations, RBAC fin, règles d'entreprise | SAML et multi-tenant via la mise à niveau Identity Platform |
| Hébergement | Cloud (régions UE) ou self-hosting | Cloud géré uniquement | Cloud Google uniquement |
| Dépendance au fournisseur | Faible : Postgres et code open source | Forte | Forte |
Les méthodes d'authentification disponibles
Supabase Auth propose plusieurs stratégies. Le bon choix dépend de votre audience et du niveau de friction acceptable à l'inscription.
| Méthode | Fonctionnement | Idéale pour |
|---|---|---|
| Email et mot de passe | Inscription classique avec vérification par email | Applications B2B, comptes durables |
| Magic link | Un lien de connexion unique envoyé par email, sans mot de passe | Produits grand public, réduction de friction |
| OAuth (Google, GitHub, Apple) | Connexion via un fournisseur tiers en un clic | SaaS, onboarding rapide, confiance |
| OTP (code par SMS ou email) | Code à usage unique à saisir | Vérification de numéro, 2FA, mobile |
Email et mot de passe
La méthode de référence. Supabase gère le hachage (bcrypt), la vérification d'email et la réinitialisation. Vous appelez signUp puis signInWithPassword, le reste est automatique.
Magic link et OTP
Le magic link supprime totalement le mot de passe : l'utilisateur clique sur le lien reçu et il est connecté. L'OTP suit la même logique avec un code court, parfait pour le mobile ou la double authentification.
OTP par SMS : quel fournisseur choisir ?
Supabase Auth n'envoie pas les SMS lui-même : il délègue l'envoi à un fournisseur que vous branchez dans le dashboard. Les fournisseurs supportés nativement sont Twilio, Twilio Verify, MessageBird, Textlocal et Vonage.
Pour des codes d'authentification fiables, privilégiez un fournisseur qui propose des routes OTP dédiées (ou transactionnelles), séparées des routes marketing : la délivrabilité est meilleure et les délais de réception sont courts, ce qui compte quand un code expire en quelques minutes. Twilio Verify est le plus simple à mettre en place, car il gère lui-même la génération et la vérification du code.
Deux réflexes avant de choisir :
- •Vérifiez le coût par SMS vers la France et les pays de vos utilisateurs : il varie fortement d'un fournisseur à l'autre
- •Gardez l'OTP par email comme solution de repli : il est inclus dans Supabase, ne coûte rien de plus que votre service d'envoi d'emails (branchez un SMTP personnalisé en production) et suffit pour la majorité des applications web
Sur une application B2B, l'OTP par SMS se réserve en pratique à la double authentification des comptes à privilèges, pas à la connexion de tous les utilisateurs.
OAuth Google, GitHub, Apple
Un clic, une redirection vers le fournisseur, un retour authentifié. C'est le meilleur ratio conversion / sécurité pour un SaaS. Il suffit d'activer le provider dans le dashboard et de renseigner les clés OAuth.
Comment Supabase Auth s'articule avec Postgres et la RLS
C'est ici que Supabase se distingue. L'utilisateur authentifié n'est pas juste une session côté application : son identifiant est injecté dans chaque requête SQL via la fonction auth.uid().
Couplée à la Row Level Security de Postgres, cette mécanique garantit qu'un utilisateur ne peut lire ou modifier que ses propres données, directement au niveau de la base. Même si votre code côté client contient un bug, la base refuse la requête.
Exemple de politique RLS classique :
create policy "Un utilisateur lit ses propres commandes"
on commandes for select
using ( auth.uid() = user_id );Cette ligne suffit à verrouiller toute une table. Sans elle, une clé API exposée côté navigateur donnerait accès à tout. Avec elle, la sécurité est portée par la base, pas par la confiance dans le frontend.
À lire aussi : Supabase RLS : sécuriser vos données avec la Row Level Security - le guide détaillé pour écrire des politiques robustes sans vous piquer avec le SQL.
Gérer les rôles et les permissions
Toutes les applications ne se contentent pas d'un seul type d'utilisateur. Un SaaS distingue souvent admin, membre et invité. Supabase offre deux approches complémentaires.
Les custom claims dans le JWT. Vous ajoutez un rôle dans les métadonnées du token via une edge function ou un trigger. Ce rôle devient lisible dans vos politiques RLS avec une condition du type auth.jwt() ->> 'role' = 'admin'.
Une table de profils dédiée. Vous créez une table profiles liée à auth.users par l'identifiant, qui stocke le rôle et les préférences. C'est la méthode la plus lisible et la plus évolutive.
- •Créez la table
profilesavec une colonnerole - •Ajoutez un trigger qui crée le profil à chaque inscription
- •Référencez ce rôle dans vos politiques RLS pour filtrer les accès
- •Ne stockez jamais un rôle sensible côté client : la vérité reste en base
Sur Wiloq, cette séparation organisateur / agent repose exactement sur ce schéma. Chaque interface n'affiche que ce que le rôle autorise, et la RLS bloque tout accès non prévu côté serveur.
Quand plusieurs organisations partagent la même base, le rôle ne suffit plus : il faut isoler les données par tenant. Nous détaillons ce découpage dans notre guide sur l'architecture multi-tenant d'un SaaS Supabase.
Bonnes pratiques de sécurité
Supabase fait le gros du travail, mais quelques règles restent à votre charge.
- •Activez la RLS sur toutes vos tables. Une table sans politique est soit ouverte, soit fermée : ne laissez jamais ce choix au hasard.
- •Ne confondez jamais la clé anon et la clé service_role. La première est publique et respecte la RLS ; la seconde ignore toutes les règles et ne doit vivre que côté serveur.
- •Exigez la vérification d'email avant d'accorder le moindre accès sensible.
- •Activez la double authentification (OTP) pour les comptes à privilèges.
- •Limitez la durée de vie des tokens et gérez le refresh proprement pour éviter les sessions éternelles.
- •Surveillez les tentatives de connexion via les logs Supabase pour détecter les attaques par force brute.
La faille la plus fréquente n'est pas dans Supabase : c'est une clé service_role exposée dans un bundle frontend. Gardez-la côté serveur, toujours.
Sessions, JWT et refresh token : ce qui se passe vraiment
À chaque connexion, Supabase Auth délivre deux jetons. L'access token est un JWT de courte durée (une heure par défaut, réglable dans le dashboard) qui accompagne chaque requête vers l'API et la base. Le refresh token sert uniquement à obtenir un nouvel access token quand le premier expire.
Trois règles à respecter :
- •Ne rallongez pas la durée du JWT pour éviter les déconnexions : rafraîchissez-le. Un JWT court limite la fenêtre d'exploitation en cas de vol de jeton.
- •Laissez le SDK gérer le refresh. Côté navigateur,
@supabase/ssrrenouvelle la session automatiquement ; côté Next.js, c'est le middleware qui s'en charge avant le rendu. - •Déconnectez proprement avec
signOut(): le refresh token est révoqué côté serveur et la session ne peut plus être prolongée. L'access token en cours reste valable jusqu'à son expiration, raison de plus pour le garder court.
Le refresh token est à usage unique et tourne à chaque renouvellement : si un ancien jeton est réutilisé en dehors d'une courte fenêtre de tolérance, Supabase détecte la tentative et révoque la session concernée. C'est ce mécanisme qui protège vos utilisateurs contre le rejeu d'un cookie volé.
Intégration côté Next.js et React
C'est le terrain de jeu favori d'ONDEV. La combinaison Supabase et Next.js permet une authentification propre, du composant client au rendu serveur.
Côté client, le SDK gère la session et l'écoute des changements d'état :
import { createBrowserClient } from '@supabase/ssr'
const supabase = createBrowserClient(url, anonKey)
// Connexion OAuth Google
await supabase.auth.signInWithOAuth({ provider: 'google' })Côté serveur, un middleware Next.js (le fichier proxy.ts depuis Next.js 16) rafraîchit la session et protège les routes avant même le rendu de la page. L'utilisateur non connecté est redirigé sans jamais voir le contenu protégé.
Le point clé : avec la librairie @supabase/ssr, la session est partagée entre le serveur et le client via des cookies sécurisés. Vos Server Components lisent l'utilisateur directement, sans appel supplémentaire.
Pour l'architecture complète de ce duo, ne manquez pas notre article dédié.
À lire aussi : Supabase et Next.js : le combo de production - pourquoi cette stack accélère le développement sans sacrifier la performance.
Vous voulez voir le résultat en production ? Notre réalisation Wiloq, application SaaS de vestiaire numérique illustre une authentification multi-rôles complète construite sur Next.js et Supabase, avec 12+ fonctionnalités déployées.
Si votre projet demande un accompagnement sur-mesure, notre agence spécialisée Supabase prend en charge l'architecture, l'authentification et la sécurité de bout en bout.
Checklist avant de passer en production
Fin septembre 2026, une étude d'UpGuard, relayée en France par Clubic, a recensé plus de 16 000 bases Supabase aux tables lisibles sans authentification, plus de la moitié contenant des indices de données personnelles. Il ne s'agissait pas d'une faille de Supabase, mais d'erreurs de configuration : des tables sans RLS ni politiques adaptées.
Le piège est subtil : les tables créées depuis le dashboard ont la RLS activée par défaut, mais celles créées en SQL, par un script de migration ou par un agent de code IA doivent l'activer explicitement. Ajoutez à cela la clé service_role embarquée côté client, et vous tenez les deux erreurs les plus fréquentes sur un projet Supabase.
Voici les 8 points que nous vérifions sur chaque projet avant la mise en ligne :
| Point de contrôle | Pourquoi |
|---|---|
| RLS activée sur toutes les tables du schéma public, y compris celles créées en SQL | Une table sans politique est lisible par n'importe qui avec la clé anon |
| Clé service_role absente du code frontend et des variables publiques | Elle ignore toutes les règles de sécurité |
| Vérification d'email obligatoire avant tout accès sensible | Bloque les comptes jetables et les inscriptions automatisées |
| Captcha activé sur l'inscription et la connexion | Supabase supporte hCaptcha et Cloudflare Turnstile en natif |
| MFA (TOTP) proposée aux comptes admin | Un mot de passe seul ne protège pas un compte à privilèges |
| Durée du JWT courte et refresh géré par le middleware | Limite la fenêtre d'exploitation d'un jeton volé |
| URL de redirection OAuth restreintes aux domaines de production | Empêche le détournement du flux de connexion |
| Politiques RLS testées avec un utilisateur non admin | Une politique écrite n'est pas une politique vérifiée |
FAQ
Supabase Auth est-il gratuit ?
Quelle différence entre Supabase Auth et la RLS ?
Peut-on migrer une authentification existante vers Supabase Auth ?
Faut-il un serveur backend en plus de Supabase Auth ?
Comment gérer les rôles admin et utilisateur avec Supabase ?
Supabase Auth envoie-t-il lui-même les SMS pour les codes OTP ?
Quelle est la durée d'une session Supabase Auth et comment gérer le refresh token ?
@supabase/ssr, le renouvellement est automatique côté navigateur et pris en charge par le middleware côté Next.js. Le refresh token est à usage unique et tourne à chaque renouvellement, ce qui bloque la réutilisation d'un jeton volé.Supabase Auth ou Auth0 : lequel choisir ?
Comment protéger une route Next.js avec Supabase Auth ?
@supabase/ssr, la rafraîchit si besoin et redirige vers la page de connexion quand aucun utilisateur n'est présent. Les Server Components lisent ensuite l'utilisateur directement depuis les cookies. Et même si le middleware laisse passer une requête par erreur, la RLS côté base refuse l'accès aux données : c'est la double protection que nous mettons en place sur chaque projet.Conclusion : une authentification solide sans réinventer la roue
Supabase Auth vous offre une authentification de niveau production en quelques heures : méthodes multiples, intégration native avec Postgres, sécurité portée par la RLS et compatibilité parfaite avec Next.js et React. C'est exactement la stack que nous utilisons en développement d'applications web sur-mesure, notamment pour Wiloq, sans serveur d'auth à maintenir.
Reste à l'implémenter proprement : politiques RLS bien pensées, gestion des rôles solide, clés bien cloisonnées, jetons courts. Une erreur ici coûte cher.
Vous lancez une application et vous voulez une authentification sécurisée dès le premier jour ? Parlons de votre projet : on construit l'architecture Supabase qui protège vos données et vos utilisateurs.
