Building an Authenticated Web App with Supabase Auth and Cloudflare

Hello, I'm Matsun from Liberogic.
This is my first time writing an article.

Security news has been constant lately, from PHP2Shell to HTTP2Shell.
Cloudflare has also announced WAF measures against PHP vulnerabilities.
I feel we need to pay more attention not only to web systems but also to staff PCs and network environments.

Our CTO, Otsuka, recently wrote about building a custom web app with Supabase and Cloudflare.
As a follow-up, I'll cover authentication, an essential part of any business application.

For internal systems and portals for business partners, simply having a login is not enough. You need to control which information and features each user can access. That's where we use Supabase Auth.

Business apps almost always require login

• Internal approval and request system
• Member-only mypage
• Partner Portal
• Time Tracking & Attendance Management
• Project Management
• Management Systems for Stores and Branch Offices

In most cases, web apps like these require a login feature.
However, being able to log in with an ID and password alone is not enough.
For example, in an internal approval system,

• General employee
• Supervisor
• Site administrator
• Head Office Administrator
• System Administrator

Even when people use the same app, what they can do varies by role.
In a partner portal, for example, Company A's staff should not be able to see Company B's information.
In authenticated web apps,

• authentication, which confirms "who the user is"
• authorization, which determines "what that user is allowed to do"

into two distinct concerns.

Consolidating login handling with Supabase Auth

Supabase Auth is the authentication feature provided by Supabase. For example,

• email address + password
• Magic Link
• one-time password (OTP)
• Social login with Google and more

and more.
For business apps, email address and password are the most common starting point, but depending on the use case, you can also have users sign in with a Magic Link without setting a password. Not having to build and operate all of this from scratch is a major advantage.
Authentication may look like a single login form on screen, but behind the scenes it involves

• User registration
• Password management
• Email address verification
• Login state management
• Password reset
• Session management

and many other processes.
Supabase can handle these core authentication features for you.

Here's how it looks when combined with Cloudflare

In our previous CTO article, we discussed

Cloudflare as the entry point and Supabase as the data foundation

. Adding authentication doesn't change the basic approach.

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

Users access the web app and log in with Supabase Auth.
Based on the authenticated user's information, the Next.js side switches which screens to show, and fetches the necessary data from Supabase.
Cloudflare continues to serve as the entry point for the web app. In practice, external APIs

• Cloudflare Workers
• R2
• SendGrid
• Box
• External API

can be added as needed.
There's no need to do everything with Supabase alone, and no need to do everything with Cloudflare alone.
Each service is used for what it does best.

Changing the screen based on who is logged in

For example, suppose we build a partner portal. When you log in, you see a screen like this:

○○株式会社
森本様

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

If someone from another company logs in, only that company's projects and materials are shown.
If an administrator logs in, they see

• all partner companies
• All Projects
• User Management
• File Management
• Audit Log

and other admin menus are displayed.
It looks simple on the surface, but behind the scenes,

the system determines who the logged-in user is

and retrieves the information linked to that user.
When using Supabase Auth, each authenticated user has an ID that identifies them, and we use that ID to link them to business data.

Don't check authentication only in the browser

When building web apps with Next.js and similar frameworks, authentication data isn't always handled only on the browser side. There are also cases where the server needs to check, "Is this user logged in?"
Supabase provides a cookie-based authentication method for SSR environments, and with Next.js, user sessions can be handled from both the client and server sides. This mechanism is very important. For example,

/login

can be viewed by anyone, but

/dashboard

for example, pages that only logged-in users can access,

/admin

and pages that only administrators can access. Access is controlled at the URL level.
Simply hiding the "Admin" button on screen does not provide real security.
We also verify access on the server and in the database, so the system stays secure even if someone opens a URL directly or calls the API directly.

Authentication and authorization are different things

Authentication and authorization need to be considered separately when designing business applications.
With Supabase Auth,

"Morimoto has logged in"

you can confirm that. However,

"Which data Morimoto should be able to see"

is a separate question. For example,

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

relationships like these need to be designed.
In business applications, this part differs greatly from app to app.
Handling only "administrators" and "general users" is simple, but

• headquarters
• Branch
• Store
• Business partner
• Agency
• External staff

Once branches, partners, or external staff come into the picture, permission design quickly becomes complex.
In Supabase, the key to controlling these permissions is **RLS (Row Level Security)**.
With RLS, you can enforce access rules on the database side as well, so that users see only

• their own data
• data from their own company
• data from their own location
• everything if they are an administrator

...and similar controls.
We'll cover the specific RLS design in an upcoming article.

Also protected on the Cloudflare side

Just because Supabase Auth is in place doesn't mean Supabase is solely responsible for the security of your web app. On the Cloudflare side,

• WAF
• DNS
• HTTPS
• bot protection
• rate limiting
• API processing with Workers
• Cloudflare Access, as needed,

can be combined. In other words,

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

the security should be considered in separate layers.
Having a login screen does not make an app secure.
In a web app, each of the entry point, application, API, and database needs appropriate controls.

Here's how this can be used in practice

Supabase Auth and Cloudflare can be used together for a wide range of business applications.

Internal Request & Approval App

• Employees log in, submit requests, and have them approved by supervisors or administrators.
• General employees can only view their own requests.
• Supervisors can access their own department.
• Administrators have access to everything.

This enables role-based access control.

Partner Portal

Accounts are issued to each client company,

• project information
• materials
• files
• Notices
• Inquiry History

It is the same web app, but the content changes depending on which company is logged in.

Member-only mypage

Only the member themselves can view their

• Registration Information
• Application History
• Contract Information
• files
• Various Settings

and other details.

Location Management System

Store and branch staff across the country log in to register information for their own locations.
Headquarters can review all locations together.
This use case can also be supported by combining Supabase Auth with permission controls.

No need to build the entire authentication infrastructure yourself

In the past, building an internal business system with authentication meant designing from the ground up: how to run the auth server, how to manage sessions, and how to connect everything to the database.
Of course, design work is still necessary today.
However, using a service like Supabase Auth reduces the work of building an authentication infrastructure from scratch. That frees up time for

• Who should see what
• Who should be able to operate what
• What business permissions are actually required

the questions that should really be considered.
Personally, I believe this is the biggest advantage of using Supabase for business applications.

Summary

By combining Supabase Auth with Cloudflare, you can build an authenticated web app with a relatively simple architecture.
However, what matters most is not building the login screen.
For authenticated users, the key questions are

• What they can see
• What they can do
• What data they can access

Only when the design is thought through to this level does it become a web application that can actually be used in business.
Supabase Auth handles verifying who the user is, and the permission control that follows is built on the application and database side.

Next time, I'll write about how to use Supabase RLS in business applications.