Créer une application web avec authentification grâce à Supabase Auth et Cloudflare

Bonjour, je suis Matsunaga de Liberogic.
C'est mon premier article.

Les actualités sécurité se succèdent, de PHP2Shell à HTTP2Shell.
Cloudflare a également annoncé des mesures WAF contre les vulnérabilités de PHP.
Je pense qu'il faut désormais porter davantage attention non seulement aux systèmes web, mais aussi aux postes de travail du personnel et à l'environnement réseau.

Plus tôt, notre CTO Otsuka a écrit à propos de la création d'une application web dédiée avec Supabase et Cloudflare.
Dans la suite de cet article, je vais aborder à mon tour un sujet indispensable aux applications métier : l'authentification.

Pour les systèmes internes et les portails destinés aux partenaires, la simple possibilité de se connecter ne suffit pas. Il faut distinguer les informations consultables et les fonctions accessibles selon les utilisateurs. C'est pour cela que nous utilisons Supabase Auth.

Les applications métier nécessitent généralement une connexion

• Système interne de demandes et d'approbations
• Espace membre
• Portail dédié aux partenaires
• Gestion des charges et des présences
• Gestion de projets
• Système de gestion pour boutiques et sites

Dans la plupart des cas, ce type d'application web nécessite une fonction de connexion.
Toutefois, il ne suffit pas de pouvoir se connecter avec un identifiant et un mot de passe.
Par exemple, pour un système de demandes internes,

• Employé
• Supérieur hiérarchique
• Administrateur de site
• Administrateur principal
• Administrateur système

Même avec la même application, comme un portail destiné aux partenaires, les actions possibles varient selon le rôle.
Dans un portail partenaires, il serait problématique que le personnel de la société A puisse consulter les informations de la société B.
Pour une application web avec authentification,

• l'authentification, qui vérifie « qui » est l'utilisateur
• la gestion des autorisations, qui définit « ce que cette personne est autorisée à faire »

il est nécessaire de distinguer ces deux notions.

Regrouper la connexion avec Supabase Auth

Supabase Auth est la fonctionnalité d'authentification proposée par Supabase. Par exemple,

• adresse e-mail + mot de passe
• Magic Link
• mot de passe à usage unique (OTP)
• Connexion sociale via Google et autres services

sont pris en charge.
Pour les applications métier, on utilise généralement une adresse e-mail et un mot de passe, mais selon les besoins, il est également possible de se connecter via un Magic Link, sans mot de passe. Ne pas avoir à implémenter et exploiter tout cela de zéro constitue un avantage considérable.
À l'écran, la authentification ressemble à un simple formulaire de connexion, mais en coulisses, il faut gérer

• l'inscription des utilisateurs
• la gestion des mots de passe
• la vérification de l'adresse e-mail
• la gestion de l'état de connexion
• la réinitialisation des mots de passe
• la gestion des sessions

et bien d'autres traitements.
Ces fonctions d'authentification de base peuvent être confiées à Supabase.

Voici à quoi cela ressemble avec Cloudflare

Dans notre précédent article sur le CTO,

Cloudflare fait office de point d'entrée, et Supabase de couche de données

nous avons vu cela. L'ajout de l'authentification ne change pas fondamentalement ce principe.

ユーザー
  ↓
Cloudflare
  ↓
Next.js
  ↓
Supabase Auth
  ↓
Supabase
 ├ Database
 └ RLS

L'utilisateur accède à l'application web et se connecte via Supabase Auth.
À partir des informations de l'utilisateur authentifié, Next.js affiche l'interface adaptée et récupère les données nécessaires depuis Supabase.
Cloudflare continue de servir de point d'entrée à l'application web. En pratique, des

• Cloudflare Workers
• R2
• SendGrid
• Box
• API externes

viennent s'ajouter selon les besoins.
Il n'est pas nécessaire de tout faire avec Supabase, ni de tout faire avec Cloudflare.
Chaque outil est utilisé pour ce qu'il fait le mieux.

Adapter l'affichage selon l'utilisateur connecté

Prenons l'exemple d'un portail destiné aux partenaires commerciaux. Une fois connecté, l'utilisateur voit

○○株式会社
森本様

現在の案件
資料一覧
お問い合わせ
アカウント設定

un écran de ce type.
Un collaborateur d'une autre entreprise qui se connecte ne voit que les projets et documents de sa propre société.
Lorsqu'un administrateur se connecte,

• tous les partenaires
• Tous les projets
• Gestion des utilisateurs
• Gestion des fichiers
• Historique des opérations

etc. Il affiche le menu réservé aux administrateurs.
Vu de l'écran, cela paraît simple, mais en coulisses,

le système détermine qui est l'utilisateur connecté

, puis récupère les informations associées à cet utilisateur.
Avec Supabase Auth, chaque utilisateur authentifié dispose d'un identifiant unique, que nous associons ensuite aux données métier.

Ne pas se fier uniquement au navigateur pour l'authentification

Lorsqu'une application Web est développée avec Next.js, les informations d'authentification ne sont pas toujours traitées uniquement côté navigateur. Il arrive aussi que le serveur doive vérifier si l'utilisateur est connecté.
Supabase propose une méthode d'authentification basée sur les cookies, adaptée aux environnements SSR, qui permet à Next.js de gérer la session utilisateur à la fois côté client et côté serveur. Ce mécanisme est essentiel. Par exemple,

/login

est accessible à tous, alors que

/dashboard

seules les personnes connectées peuvent accéder à

/admin

l'accès est contrôlé au niveau de chaque URL, par exemple seuls les administrateurs peuvent accéder à certaines pages.
Masquer simplement le bouton « Administrer » à l'écran ne suffit pas à assurer la sécurité.
Il faut aussi vérifier les droits côté serveur et côté base de données, afin que l'application reste sûre même si quelqu'un ouvre une URL directement ou appelle directement l'API.

Authentification et gestion des droits sont deux choses distinctes

Lors de la conception d'une application métier, l'authentification et la gestion des droits doivent être traitées séparément.
Avec Supabase Auth,

« Mme Morimoto s'est connectée »

on peut vérifier ce fait. En revanche,

« Mme Morimoto doit-elle consulter ces données ? »

est une tout autre question. Par exemple,

ユーザー
 ↓
所属会社
 ↓
所属拠点
 ↓
役割
 ↓
閲覧できるデータ

il faut concevoir ce type de relation.
Dans une application métier, cette partie varie énormément d'une application à l'autre.
Avec seulement « administrateur » et « utilisateur standard », c'est simple, mais

• siège
• succursale
• magasin
• partenaire commercial
• agence partenaire
• personnel externe

Dès que des
partenaires ou du personnel externe entrent dans le périmètre, la conception des droits se complexifie rapidement.
Dans le cas de Supabase, le point clé de ce contrôle d'accès est **RLS (Row Level Security)**. Avec RLS, la restriction s'applique directement côté base de données, et

• uniquement ses propres données
• uniquement les données de la même entreprise
• uniquement les données du même site
• tout pour les administrateurs

…et bien d'autres contrôles encore.
La conception détaillée de RLS fera l'objet d'un prochain article.

Protection également côté Cloudflare

Le fait que Supabase Auth soit en place ne signifie pas pour autant que la sécurité de l'application web repose entièrement sur Supabase. Côté Cloudflare,

• WAF
• DNS
• HTTPS
• protection contre les bots
• limitation de débit
• traitement des API via Workers
• Cloudflare Access si nécessaire

peuvent être combinés selon les besoins. En somme,

Cloudflare
   ↓
Webアプリ
   ↓
Supabase Auth
   ↓
権限制御
   ↓
Database

nous raisonnons en plusieurs couches.
Le fait qu'il existe un écran de connexion ne suffit pas à garantir la sécurité.
Une application web doit contrôler correctement chacun de ses niveaux : le point d'entrée, l'application, l'API et la base de données.

Exemples d'utilisation dans ce type d'application

La combinaison de Supabase Auth et de Cloudflare peut être utilisée dans de nombreuses applications métier.

Application interne de demande et d'approbation

• Les collaborateurs se connectent, enregistrent leurs demandes, et les supérieurs ou administrateurs les approuvent
• Les employés standard ne peuvent accéder qu'à leurs propres demandes
• Les supérieurs hiérarchiques accèdent aux demandes de leur service
• Les administrateurs accèdent à l'ensemble des demandes

Ces droits d'accès sont contrôlés selon les rôles définis.

Portail dédié aux partenaires

Des comptes sont créés pour chaque partenaire commercial, et

• informations sur les projets
• documents
• fichiers
• Actualités
• Historique des demandes

Affiche notamment ces informations.
Il s'agit de la même application Web, mais son contenu varie selon l'entreprise connectée.

Espace membre

Seul le membre concerné peut consulter

• ses informations d'inscription
• son historique de demandes
• les informations de son contrat
• fichiers
• ses paramètres

et de les vérifier.

Système de gestion multi-sites

Les responsables des magasins et agences situés dans tout le pays se connectent et enregistrent les informations de leur propre site.
Le siège peut consulter l'ensemble des sites de manière centralisée.
Ces usages peuvent également être mis en place avec Supabase Auth et un contrôle des droits.

Il n'est plus nécessaire de créer soi-même toute l'infrastructure d'authentification

Auparavant, pour créer un système métier avec authentification, il fallait d'abord définir la manière de gérer le serveur d'authentification, la gestion des sessions et le lien avec la base de données.
Bien sûr, la conception reste nécessaire aujourd'hui.
Toutefois, l'utilisation d'un dispositif comme Supabase Auth réduit le travail de construction de l'infrastructure d'authentification à partir de zéro. Le temps ainsi gagné permet de

• définir qui peut voir quoi
• définir qui peut faire quoi
• déterminer quels droits sont nécessaires dans le cadre métier

se consacrer aux réflexions qui devraient réellement être menées.
Personnellement, je pense que c'est là le principal avantage de Supabase pour les applications métier.

Conclusion

En combinant Supabase Auth et Cloudflare, il est possible de créer une application web authentifiée même avec une architecture relativement simple.
Toutefois, l'essentiel n'est pas de créer un écran de connexion.
Pour les utilisateurs authentifiés, il faut surtout définir

• ce qui doit être affiché
• ce qui peut être fait
• quelles données sont accessibles

Ce n'est qu'en allant jusqu'à la conception que l'on obtient une application Web réellement utilisable dans le cadre professionnel.
Supabase Auth se charge de vérifier « qui est l'utilisateur ». Le contrôle des droits qui suit s'organise ensuite côté application et base de données.

Dans le prochain article, nous verrons comment utiliser RLS de Supabase dans une application métier.