使用 Supabase Auth 與 Cloudflare 打造含身分驗證的 Web 應用程式

初次見面，我是 Liberogic 的 Matsun。
這是我第一次撰寫文章。

從 PHP2Shell 到 HTTP2Shell，資安相關的新聞持續不斷。
Cloudflare 也已公布針對 PHP 漏洞的 WAF 防護措施。
我認為今後不只要關注 Web 系統，也需要更加重視員工的電腦與網路環境。

前幾天，CTO大塚寫了一篇關於使用Supabase與Cloudflare打造專用Web應用程式的文章。
這次接續前文，我將從自己的角度，談談業務應用程式不可或缺的「認證」功能。

在內部系統或面向客戶與合作夥伴的入口網站中，僅能登入是不夠的。必須依使用者區分可檢視的資訊與可使用的功能。為此，我們採用的是Supabase Auth。

業務應用程式通常都需要登入

• 內部申請與審核系統
• 會員專屬頁面
• 客戶專用入口網站
• 工時與出勤管理
• 專案管理
• 門市與據點適用的管理系統

這類 Web 應用程式大多都需要登入功能。
但僅能「輸入 ID 與密碼登入」是不夠的。
例如在內部申請系統中，

• 一般員工
• 主管
• 據點管理者
• 本部管理者
• 系統管理者

即使使用相同的應用程式，如 A 公司與 B 公司等，也會因立場不同而可執行的操作有所差異。
若是供交易對象使用的入口網站，A 公司的負責人不應能瀏覽 B 公司的資訊。
在需要驗證的網頁應用程式中，

• 確認「使用者是誰」的身分驗證
• 決定「該使用者可以做什麼」的權限管理

需要分開考量。

使用 Supabase Auth 統一管理登入部分

Supabase Auth 是 Supabase 提供的身分驗證功能。例如，

• 電子郵件地址 + 密碼
• Magic Link
• 一次性密碼（OTP）
• 使用 Google 等的社群登入

等方式。
業務應用程式通常以電子郵件地址與密碼為主要登入方式，但視用途而定，也可以不設定密碼，改用 Magic Link 登入。從零開始全部由自家團隊實作與維運這些機制並不需要，這點是很大的優勢。
從畫面上看，認證功能似乎只是一個登入表單，但在背後，

• 使用者註冊
• 密碼管理
• 電子郵件地址驗證
• 登入狀態管理
• 密碼重設
• 工作階段管理

等多項處理。
這些認證相關的基礎功能，可以交由 Supabase 負責。

與 Cloudflare 搭配使用的示意

上一篇關於 CTO 的文章中，

我們提到 Cloudflare 負責入口、Supabase 負責資料基礎，

而即使加入了驗證機制，基本概念也是相同的。

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

使用者存取 Web 應用程式並透過 Supabase Auth 登入。
系統會根據已驗證使用者的資訊，在 Next.js 端切換顯示的畫面，或從 Supabase 取得所需的資料。
Cloudflare 仍然作為 Web 應用程式的入口繼續使用。實際上，在這裡還會依需要加入

• Cloudflare Workers
• R2
• SendGrid
• Box
• 外部 API

等服務。
不需要把所有功能都只交給 Supabase 處理，也不必全部都只靠 Cloudflare。
我們會依各項服務的特性，分別使用最適合的工具。

依登入使用者切換畫面

舉例來說，假設我們要建立一個供合作廠商使用的入口網站。使用者登入後，

○○株式会社
森本様

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

會看到如下的畫面。
若是其他公司的人員登入，系統只會顯示該公司的專案與資料。
若管理員登入，則會顯示

• 所有合作廠商
• 全部案件
• 使用者管理
• 檔案管理
• 操作紀錄

等管理者專用選單。
單看畫面會覺得很單純，但在背後，

系統會判斷目前登入的是哪一位使用者

，並取得與該使用者相關的資料。
使用 Supabase Auth 時，每位通過驗證的使用者都會有用來識別身分的 ID，我們會將它與業務資料相互關聯。

不要只在瀏覽器端檢查驗證狀態

使用 Next.js 等框架開發 Web 應用程式時，驗證資訊不一定只在瀏覽器端處理。伺服器端也常需要確認「這位使用者是否已登入」。
Supabase 為 SSR 環境提供了以 Cookie 為基礎的驗證方式，在 Next.js 中，客戶端與伺服器端都能處理使用者的工作階段，這個機制非常重要。舉例來說，

/login

任何人都可以看見，但

/dashboard

只限已登入的使用者，

/admin

或只限管理員，依網址單位控制存取權限。
單純隱藏畫面上的「管理」按鈕並不能構成安全機制。
即使有人直接開啟網址或直接呼叫 API，系統仍需在伺服器端與資料庫端進行確認。

驗證與權限管理是不同的事

設計業務應用程式時，驗證與權限管理需要分開考量。
使用 Supabase Auth，

「森本已登入」

這一點可以確認。但是，

「森本可以查看哪些資料」

則是另一個問題。例如，

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

等關係都需要加以設計。
在業務應用程式中，這個部分會因應用程式而有很大差異。
若只有「管理員」與「一般使用者」，設計相對簡單，但是，

• 總部
• 分公司
• 門市
• 往來客戶
• 代理商
• 外部人員

當分公司、門市、往來客戶、代理商或外部人員等角色加入後，權限設計會變得相當複雜。
而若使用 Supabase，在權限控制上最關鍵的是 **RLS（Row Level Security，列級安全性）**。
使用 RLS 時，不論在資料庫端或

• 僅限自己的資料
• 僅限同一間公司的資料
• 僅限同一據點的資料
• 管理員則可存取全部

可以進行這類控制。
RLS 的具體設計，將在下一篇文章中說明。

也在 Cloudflare 端進行防護

即使有 Supabase Auth，也不代表 Web 應用程式的安全性完全交由 Supabase 負責。在 Cloudflare 端，

• WAF
• DNS
• HTTPS
• Bot 防護
• 速率限制
• 透過 Workers 處理 API
• 視需要搭配 Cloudflare Access

等功能組合運用。換言之，

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

我們會將其分成數個層級來思考。
「有登入畫面就安全」並不是這樣的。
Web 應用程式需要分別在入口、應用程式、API 與資料庫等各個層級進行適當的控制。

例如可用於以下這類應用程式

Supabase Auth 與 Cloudflare 的組合，可應用於各式各樣的業務應用程式。

內部申請・審核應用程式

• 員工登入後登錄申請，由主管或管理員進行核准
• 一般員工僅能檢視自己的申請
• 主管可檢視所屬部門
• 管理員可檢視全體

等權限控管。

客戶專用入口網站

為每家往來廠商核發帳號，

• 案件資訊
• 資料
• 檔案
• 公告
• 諮詢紀錄

等內容。
雖然是同一個 Web 應用程式，但依登入的公司不同，顯示的內容也會有所差異。

會員專屬頁面

僅限會員本人可以

• 查看登錄資料
• 申請紀錄
• 合約資訊
• 檔案
• 各項設定

等資料。

據點管理系統

全國各地門市與營業據點的負責人登入後，即可登錄所屬據點的資訊。
總公司端可以統一確認所有據點的資料。
此類用途也能結合 Supabase Auth 與權限控制一併使用。

不必從頭自行建置認證基礎架構

過去若要開發需要登入驗證的業務系統，首先必須設計認證伺服器要如何架設、工作階段（Session）要如何管理，以及如何與資料庫連結。
當然，現在仍然需要進行這些設計。
不過透過使用 Supabase Auth 這類機制，可以減少從零建置認證基礎架構的工作量。因此能將時間投入在

• 誰可以看到什麼內容
• 誰可以操作什麼功能
• 業務上需要哪些權限

等真正應該思考的問題上。
個人認為，這一點正是在業務應用程式中使用 Supabase 的一大優勢。

總結

結合 Supabase Auth 與 Cloudflare，即使架構相對簡單，也能開發出具備認證功能的 Web 應用程式。
但關鍵不在於建立登入畫面。
對於已通過認證的使用者，

• 要讓他們看到什麼內容
• 要讓他們能操作哪些功能
• 要讓他們能存取哪些資料

設計到位後，才能成為可實際用於業務的 Web 應用程式。
Supabase Auth 負責確認「使用者是誰」，之後的權限控制則是在應用程式與資料庫端組合實現，大致是這樣的架構概念。

下一篇將介紹如何在業務應用程式中使用 Supabase 的 RLS。