Een webapp met authenticatie bouwen met Supabase Auth en Cloudflare

Hallo, ik ben Matsunn van Liberogic.
Dit is mijn eerste artikel.

Na PHP2Shell en nu HTTP2Shell blijven de beveiligingsnieuwsberichten binnenstromen.
Cloudflare heeft ook WAF-maatregelen aangekondigd tegen kwetsbaarheden in PHP.
Ik vind dat we niet alleen naar webapplicaties moeten kijken, maar ook meer aandacht moeten besteden aan de pc's van medewerkers en de netwerkomgeving.

Onze CTO Otsuka schreef onlangs over het bouwen van een eigen webapplicatie met Supabase en Cloudflare.
In dit vervolg bespreek ik vanuit mijn kant een onderwerp dat onmisbaar is voor zakelijke applicaties: authenticatie.

Bij interne systemen en portalen voor zakelijke partners is alleen inloggen niet genoeg. Gebruikers moeten alleen de informatie kunnen zien en de functies kunnen gebruiken die voor hen bedoeld zijn. Daarvoor gebruiken wij Supabase Auth.

Zakelijke applicaties vereisen meestal inloggen

• Intern aanvraag- en goedkeuringssysteem
• Ledenportaal
• Portaal voor zakelijke partners
• Urenregistratie en personeelsbeheer
• Projectbeheer
• Beheersysteem voor winkels en vestigingen

Bij dit soort webapplicaties is inloggen bijna altijd nodig.
Maar het is niet voldoende dat gebruikers alleen een ID en wachtwoord invoeren.
Denk bijvoorbeeld aan een intern aanvraagsysteem, waarbij

• Medewerker
• Leidinggevende
• Locatiebeheerder
• Hoofdbeheerder
• Systeembeheerder

Ook wanneer dezelfde app wordt gebruikt, verschilt wat je kunt doen per rol.
Bij een portaal voor leveranciers of klanten wil bedrijf A bijvoorbeeld niet dat medewerkers van bedrijf B hun gegevens kunnen zien.
Bij een webapplicatie met inlogfunctie moet je daarom twee dingen apart bekijken:

• wie iemand is, vastgesteld via authenticatie
• wat iemand mag doen, bepaald via autorisatiebeheer

.

Het inlogproces centraliseren met Supabase Auth

Supabase Auth is de authenticatiefunctie die bij Supabase wordt aangeboden. Voorbeelden zijn:

• e-mailadres + wachtwoord
• Magic Link
• eenmalig wachtwoord (OTP)
• Social login via Google and more

en meer.
Voor zakelijke apps begint men meestal met e-mailadres en wachtwoord, maar afhankelijk van het gebruik kun je ook een Magic Link gebruiken zodat er geen wachtwoord nodig is. Het is een groot voordeel dat je deze onderdelen niet helemaal zelf vanaf nul hoeft te bouwen en beheren.
Authenticatie lijkt op het scherm misschien alleen een inlogformulier, maar achter de schermen gaat het om

• Gebruikersregistratie
• Wachtwoordbeheer
• Verificatie van e-mailadres
• Beheer van inlogstatus
• Wachtwoord opnieuw instellen
• Sessiebeheer

en nog veel meer processen.
Supabase kan deze basisfunctionaliteit rond authenticatie voor je afhandelen.

Zo ziet het eruit in combinatie met Cloudflare

In ons vorige artikel over de CTO schreven we al

Cloudflare als toegangspunt en Supabase als databasislaag

, en het toevoegen van authenticatie verandert niets aan die basisgedachte.

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

Gebruikers openen de webapp en loggen in met Supabase Auth.
Op basis van de gegevens van de geauthenticeerde gebruiker toont de Next.js-kant verschillende schermen, en haalt de app de benodigde gegevens op uit Supabase.
Cloudflare blijft fungeren als toegangspunt voor de webapp. In de praktijk voegen we hieraan, waar nodig,

• Cloudflare Workers
• R2
• SendGrid
• Box
• externe API's

toe.
Het is niet nodig alles via Supabase te doen, en ook niet alles via Cloudflare.
Elke dienst wordt gebruikt waarvoor hij het sterkst is.

Het scherm laten variëren per ingelogde gebruiker

Stel dat we een portaal voor zakelijke partners bouwen. Na het inloggen ziet de gebruiker

○○株式会社
森本様

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

een scherm zoals hieronder.
Logt iemand van een andere organisatie in, dan toont het scherm alleen de projecten en documenten van die organisatie.
Logt een beheerder in, dan ziet die

• alle zakelijke partners
• Alle projecten
• Gebruikersbeheer
• Bestandsbeheer
• Activiteitenlogboek

enz., en toont het menu voor beheerders.
Aan de oppervlakte lijkt het eenvoudig, maar achter de schermen gebeurt het volgende:

wie de ingelogde gebruiker is

wordt vastgesteld, waarna de gegevens die bij die gebruiker horen worden opgehaald.
Met Supabase Auth krijgt elke geauthenticeerde gebruiker een unieke ID, die we koppelen aan de bedrijfsgegevens.

Authenticatie niet alleen in de browser

Bij webapplicaties met Next.js worden authenticatiegegevens niet altijd alleen aan de browserkant verwerkt. Ook op de server is het vaak nodig te controleren of iemand is ingelogd.
Supabase biedt voor SSR-omgevingen een authenticatiemethode op basis van cookies, en met Next.js kan de sessie van de gebruiker zowel aan de clientkant als aan de serverkant worden beheerd. Dit mechanisme is erg belangrijk. Bijvoorbeeld:

/login

is voor iedereen zichtbaar, maar

/dashboard

is alleen toegankelijk voor ingelogde gebruikers,

/admin

is alleen voor beheerders. We regelen toegang ook op URL-niveau.
Simpelweg de knop "Beheren" op het scherm verbergen is geen beveiliging.
Ook als iemand een URL rechtstreeks opent of de API rechtstreeks aanroept, moet alles veilig blijven, dus we controleren dit ook aan de serverzijde en in de database.

Authenticatie en autorisatie zijn twee verschillende zaken

Bij het ontwerpen van een bedrijfsapplicatie moet je authenticatie en autorisatie apart bekijken.
Met Supabase Auth kun je zien dat,

"Meneer Morimoto is ingelogd"

is dus vast te stellen. Maar

"welke gegevens mag meneer Morimoto eigenlijk inzien?"

is een heel andere vraag. Denk bijvoorbeeld aan

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

Zulke relaties moet je ontwerpen.
In bedrijfsapplicaties verschilt dit per applicatie enorm.
Met alleen "beheerder" en "gewone gebruiker" is het eenvoudig, maar

• hoofdkantoor
• filiaal
• vestiging
• zakelijke partner
• dealer
• externe medewerkers

Zodra er ook zoiets als vestigingen, partners of externe medewerkers bijkomen, wordt het ontwerpen van rechten al snel ingewikkeld.
Bij Supabase is hierbij **RLS (Row Level Security)** cruciaal.
Met RLS kun je, ook aan de kant van de database, ervoor zorgen dat

• gebruikers alleen hun eigen gegevens zien
• gebruikers alleen gegevens van hun eigen bedrijf zien
• gebruikers alleen gegevens van hun eigen vestiging zien
• beheerders alles kunnen zien

...en dergelijke controles kunnen worden uitgevoerd.
De specifieke ontwerpdetails van RLS behandelen we in een volgend artikel.

Ook beveiligen met Cloudflare

Dat Supabase Auth wordt gebruikt, betekent niet dat de beveiliging van de webapplicatie volledig aan Supabase wordt overgelaten. Aan de Cloudflare-kant kan het volgende worden ingezet:

• WAF
• DNS
• HTTPS
• botbeveiliging
• snelheidsbeperking
• API-verwerking met Workers
• indien nodig Cloudflare Access

en meer. Kortom,

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

Zo denken we in verschillende lagen.
Een inlogscherm betekent niet automatisch dat een applicatie veilig is.
Bij webapplicaties moet de toegang op elk niveau goed worden beheerd: de toegangspoort, de applicatie, de API en de database.

Zo kan dit bijvoorbeeld worden gebruikt in deze apps

Supabase Auth en Cloudflare kunnen samen worden gebruikt in allerlei bedrijfsapplicaties.

Interne aanvraag- en goedkeuringsapp

• Medewerkers loggen in, dienen aanvragen in en worden goedgekeurd door hun leidinggevende of een beheerder
• Gewone medewerkers zien alleen hun eigen aanvragen
• Leidinggevenden zien hun eigen afdeling
• Beheerders zien alles

zijn voorbeelden van rechtenbeheer.

Portaal voor zakelijke partners

Per klant wordt een account aangemaakt,

• projectinformatie
• documenten
• bestanden
• Mededelingen
• Contactgeschiedenis

enzovoort.
Het is dezelfde webapp, maar de inhoud verandert afhankelijk van het bedrijf waarmee u bent ingelogd.

Ledenportaal

Alleen het lid zelf kan

• registratiegegevens
• aanvraaggeschiedenis
• contractgegevens
• bestanden
• instellingen

controleren.

Beheersysteem voor vestigingen

Medewerkers van winkels en kantoren door het hele land loggen in en registreren de gegevens van hun eigen vestiging.
Het hoofdkantoor kan alle vestigingen gezamenlijk bekijken.
Voor dit soort gebruik kunt u Supabase Auth combineren met rechtenbeheer.

Je hoeft de authenticatie-infrastructuur niet meer helemaal zelf te bouwen

Vroeger moest je bij het bouwen van een zakelijk systeem met authenticatie beginnen met het ontwerp: hoe richt je de authenticatieserver in, hoe beheer je sessies en hoe koppel je dat aan de database.
Uiteraard is ontwerp ook nu nog nodig.
Maar door een oplossing als Supabase Auth te gebruiken, hoef je de authenticatie-infrastructuur niet vanaf nul op te bouwen. Zo blijft er meer tijd over voor

• wat wie mag zien
• wat wie mag bedienen
• welke rechten de bedrijfsvoering vereist

: de vragen die je eigenlijk zou moeten beantwoorden.
Persoonlijk vind ik dit het grootste voordeel van Supabase voor zakelijke applicaties.

Conclusie

Met Supabase Auth en Cloudflare kun je ook met een relatief eenvoudige opzet een webapplicatie met authenticatie bouwen.
Het belangrijkste is echter niet het bouwen van het inlogscherm.
Het gaat erom wat je geauthenticeerde gebruikers mogen zien en doen, en tot welke data ze toegang hebben.

• Wat er getoond wordt
• Wat er bediend kan worden
• Tot welke data toegang bestaat

Pas wanneer de applicatie tot in het detail is uitgewerkt, is het een webapp die je zakelijk daadwerkelijk kunt gebruiken.
Supabase Auth verzorgt de identiteitscontrole, het vaststellen van wie de gebruiker is. Daarna bouw je de autorisatie, het bepalen wat iemand mag doen, op in de applicatie en de database.

In de volgende post laat ik zien hoe je Supabase RLS in zakelijke applicaties inzet.