Supabase Auth : guide authentification

Combien de temps faut-il pour coder une authentification complète ? Avec Supabase Auth, une après-midi suffit.

L'authentification, c'est le mur que 80% des projets rencontrent en premier. Gestion des sessions, hachage des mots de passe, OAuth, réinitialisation, tokens qui expirent : chaque brique mal posée devient une faille de sécurité. Supabase Auth règle ce chantier en quelques lignes, avec une base Postgres et la Row Level Security derrière.

Dans cet article, vous allez découvrir :

• •Les 4 méthodes d'authentification (email, magic link, OAuth, OTP) et quand choisir chacune
• •Comment Supabase Auth se connecte à votre base Postgres et sécurise chaque requête via la RLS
• •La méthode concrète pour gérer les rôles et les permissions sans usine à gaz
• •L'intégration côté Next.js et React, du client au middleware, telle qu'on la déploie chez ONDEV

Sur Wiloq, notre SaaS de vestiaire numérique en production, toute l'authentification (inscription, connexion, rôles organisateur et agent) tourne sur Supabase Auth avec zéro 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.

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.

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.

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.

A 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 profiles avec une colonne role
• •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.

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.

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 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é.

A lire aussi : Supabase et Next.js : le combo parfait pour votre app - 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.

FAQ

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 qui fait tourner nos SaaS comme Wiloq ou Swap&Share, 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. 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.