Supabase Auth est le système de connexion intégré à Supabase : il stocke les utilisateurs dans la base Postgres de votre projet, les connecte par mot de passe, lien magique, code à usage unique ou via un fournisseur comme Google, et émet la session que lisent les règles de votre base de données. Pour ajouter une connexion à une application web, vous demandez à votre créateur d'app IA les méthodes de connexion et les rôles, puis vous vérifiez trois réglages dans le tableau de bord Supabase : la Site URL, les URL de redirection et l'expéditeur des e-mails.
Ce guide explique le rôle de chaque élément, les choix qui comptent et les phrases à mettre dans votre prompt. Pour les règles d'accès elles-mêmes, lisez notre guide sur la row level security de Supabase.
Ce que Supabase Auth fait, et ce qu'il ne fait pas
Supabase Auth prouve qui est l'utilisateur ; il ne décide pas de ce que cet utilisateur peut voir. Sa documentation liste les méthodes de connexion : mot de passe, lien magique, mot de passe à usage unique, connexion sociale (Apple, Google, GitHub et tout fournisseur OAuth2 ou OIDC), téléphone via des fournisseurs comme Twilio, et authentification unique SAML pour les entreprises. Les données des utilisateurs vivent dans un schéma spécial de votre propre base Postgres.
Ce qu'un utilisateur a le droit de faire relève d'une seconde couche. Le client Supabase envoie le jeton de l'utilisateur avec chaque requête, et les politiques de row level security de la base s'en servent pour filtrer les lignes. L'authentification répond à « qui est-ce ? », et les politiques répondent à « quelles lignes cette personne peut-elle lire ou modifier ? ». Une app avec connexion mais sans politiques est ouverte à tous.
Quelle méthode de connexion choisir
Choisissez la méthode qui correspond aux habitudes de vos utilisateurs : Google pour un public grand public ou des startups, e-mail et mot de passe pour des outils métier, lien magique quand les gens se connectent rarement. Chacune a un coût, résumé ci-dessous.
| Méthode | Adaptée à | Avantages | Inconvénients |
|---|---|---|---|
| E-mail et mot de passe | Outils métier, portails clients | Familière, fonctionne avec n'importe quelle adresse, pas de tiers | Demande des e-mails de confirmation et de réinitialisation ; les utilisateurs oublient leur mot de passe |
| Lien magique ou code par e-mail | Connexions rares, clients peu techniques | Aucun mot de passe à stocker ni à oublier | Chaque connexion envoie un e-mail : la délivrabilité et les limites d'envoi comptent |
| OAuth (Google, GitHub) | Apps grand public, startups, outils pour développeurs | Un clic, pas de réinitialisation de mot de passe, pas d'e-mail à envoyer | Il faut créer les identifiants du fournisseur et enregistrer l'URL de redirection ; tous les clients n'ont pas le compte |
| Code par téléphone | Marchés où le téléphone fait office d'identité | Rapide sur mobile | Demande un compte chez un fournisseur de SMS, qui facture chaque message |
| SSO entreprise (SAML) | Vente à de grandes entreprises | Les entreprises gèrent les accès de façon centralisée | Configuration pour chaque client ; vérifiez les conditions de l'offre sur la page de tarifs de Supabase |
Confirmation par e-mail et réinitialisation du mot de passe
Quand la confirmation par e-mail est activée, un nouvel utilisateur ne peut pas se connecter tant qu'il n'a pas cliqué sur le lien du message. La page de configuration de Supabase indique que si vous la désactivez, l'e-mail est considéré comme confirmé sans aucune vérification. Gardez-la activée dès qu'il y a de vrais utilisateurs : sans elle, n'importe qui peut créer un compte avec une adresse qui n'est pas la sienne.
La réinitialisation du mot de passe fonctionne de la même façon : l'utilisateur demande un lien, reçoit un e-mail et arrive sur une page de votre app où il choisit un nouveau mot de passe. Ces deux parcours dépendent de deux éléments que vous maîtrisez : les réglages de redirection ci-dessous et l'expéditeur des e-mails. Si un lien de confirmation ouvre « localhost » ou une page d'erreur, la cause est presque toujours dans les réglages de redirection.
Les sessions : ce qui se passe après la connexion
Après la connexion, Supabase donne au navigateur un jeton d'accès de courte durée et un jeton de rafraîchissement, et la bibliothèque cliente les renouvelle sans redemander à l'utilisateur de se reconnecter. D'après la documentation sur les sessions, le jeton d'accès est un JWT qui expire au bout d'une heure par défaut, et chaque jeton de rafraîchissement ne peut servir qu'une seule fois. Si un ancien jeton de rafraîchissement est rejoué en dehors d'une courte fenêtre, la session entière est terminée.
Pour un utilisateur de créateur d'app, l'essentiel est que vous écrivez rarement du code de session. Vous demandez « garder les utilisateurs connectés » et « rediriger vers la page de connexion quand on est déconnecté », et l'app générée s'appuie sur la bibliothèque cliente pour le reste.
auth.users ou une table profiles
Gardez l'enregistrement de connexion dans auth.users et tout le reste concernant la personne dans une table à vous, généralement appelée profiles. Le guide Supabase sur la gestion des données utilisateur explique pourquoi : le schéma auth n'est pas exposé dans l'API automatique, donc votre app ne peut pas le lire directement. Le modèle recommandé est une table publique profiles dont l'id référence auth.users avec on delete cascade, avec la row level security activée, et un déclencheur (trigger) qui crée la ligne de profil après chaque inscription.
Le même guide prévient qu'un déclencheur en échec peut bloquer les inscriptions : testez-le donc avec un vrai nouveau compte après chaque modification de la table. C'est une cause fréquente de l'erreur « Database error saving new user » quand une IA modifie le schéma.
Les rôles : admin, membre, client
Stockez le rôle dans votre propre table, pas dans l'enregistrement de connexion, et laissez la row level security le faire respecter. Une colonne comme role sur profiles convient pour une seule organisation. Quand une même personne peut appartenir à plusieurs entreprises ou espaces de travail, utilisez plutôt une table memberships (utilisateur, organisation, rôle), pour qu'elle puisse être admin dans l'une et client dans l'autre.
Masquer un élément de menu aux clients n'est pas de la sécurité : c'est la base de données qui doit refuser la requête. Une politique du type « un client ne peut lire que les factures dont le client_id correspond à sa propre appartenance » le fait. Ne laissez jamais les utilisateurs modifier leur propre colonne de rôle ; la politique sur profiles doit autoriser la modification du nom et de l'avatar, pas du rôle.
Inscription sur invitation pour les outils internes et les portails
Pour un outil interne ou un portail client, désactivez l'inscription ouverte et créez les comptes uniquement sur invitation. Supabase propose un réglage « Allow new users to sign up » ; quand il est désactivé, seuls les utilisateurs existants peuvent se connecter. L'invitation elle-même, qui crée l'utilisateur, attribue le rôle et envoie l'e-mail, doit s'exécuter côté serveur, dans une edge function, car elle nécessite une clé secrète qui ne doit jamais atteindre le navigateur.
Le parcours à demander : un admin saisit un e-mail et un rôle, le serveur crée l'utilisateur et la ligne d'appartenance, et la personne invitée reçoit un lien pour définir son mot de passe. Nos guides sur les outils internes et les portails clients montrent où cela s'insère dans une app complète.
Site URL et URL de redirection
La Site URL est l'adresse par défaut vers laquelle Supabase renvoie les utilisateurs, et les URL de redirection forment une liste d'autorisation d'autres adresses qu'il peut utiliser. La documentation sur les URL de redirection précise que la Site URL vaut au départ http://localhost:3000 et doit être remplacée par votre adresse de production, car les confirmations par e-mail et les réinitialisations de mot de passe en dépendent.
Ajoutez chaque adresse réelle depuis laquelle votre app est servie : votre domaine de production, votre domaine personnalisé si vous en avez un, et toute adresse de préproduction sur laquelle vous testez. La documentation recommande des chemins exacts en production et les jokers surtout pour le développement local et les prévisualisations. L'échec classique : une app publiée dont les e-mails pointent encore vers localhost, ou un domaine personnalisé ajouté plus tard et jamais enregistré.
Limites d'e-mails et SMTP personnalisé
Le service d'envoi intégré de Supabase sert uniquement aux tests : en novembre 2026, sa documentation indique qu'il est limité à 2 messages par heure, qu'il n'envoie qu'aux adresses de l'équipe de votre organisation et qu'il n'offre aucune garantie de livraison. Ces chiffres peuvent changer sans préavis ; lisez donc la page sur le SMTP personnalisé avant le lancement.
Avant l'arrivée de vrais utilisateurs, branchez votre propre fournisseur (la page cite Resend, AWS SES, Postmark, SendGrid, ZeptoMail et Brevo en exemples). La même page précise qu'un SMTP personnalisé démarre à 30 messages par heure, ajustable sur la page des limites de débit, et recommande d'authentifier votre domaine d'envoi avec DKIM, SPF et DMARC. Si votre premier utilisateur test ne reçoit jamais l'e-mail de confirmation, voilà l'explication, pas un bug de votre app.
Comment Cadrant le met en place
Cadrant, notre créateur d'app, utilise Supabase Auth dans un projet Supabase qui appartient à votre propre compte Supabase : les comptes utilisateurs restent donc les vôtres. Selon notre documentation sur l'authentification, il génère les pages de connexion et d'inscription, configure l'inscription par e-mail et mot de passe, protège les routes qui exigent une session et gère les sessions. Les fournisseurs OAuth comme Google, c'est vous qui les activez dans le tableau de bord Supabase, sous Authentication, Providers.
L'IA écrit les migrations avec la row level security sur les tables propres à chaque utilisateur, et peut lire le schéma et les politiques actuels avant de les modifier. Les rôles sont décrits dans le prompt et stockés dans des colonnes ou des tables de votre base. Les secrets, comme la clé d'un fournisseur d'e-mails, restent dans des variables d'environnement derrière des edge functions. Limites à connaître : la Site URL, les URL de redirection, les identifiants des fournisseurs et le SMTP personnalisé sont des réglages Supabase que vous vérifiez vous-même, et vous devez tester chaque rôle à la main avant d'inviter des clients. Voir aussi notre présentation de Supabase avec un créateur d'app IA.
Phrases de prompt à coller dans votre créateur d'app IA
Décrivez les personnes et les règles, pas le code. Ces phrases fonctionnent dans la plupart des créateurs :
- « Ajoute la connexion par e-mail et mot de passe et avec Google. Les utilisateurs doivent confirmer leur e-mail avant de se connecter. »
- « Crée une table profiles liée aux utilisateurs d'authentification, remplie automatiquement à l'inscription, avec une colonne role (admin, membre, client). Les utilisateurs peuvent modifier leur nom, jamais leur rôle. »
- « L'inscription est fermée. Seul un admin peut inviter un utilisateur par e-mail et choisir son rôle, depuis une fonction côté serveur. »
- « Un client ne voit que ses propres enregistrements. Un membre voit toute l'équipe. Un admin voit tout et gère les utilisateurs. Fais respecter cela par la row level security, pas seulement dans l'interface. »
- « Ajoute un lien Mot de passe oublié et une page pour définir un nouveau mot de passe. Redirige les utilisateurs déconnectés vers la page de connexion. »