--- title: "Supabase AuthとCloudflareで認証付きWebアプリを作る" date: 2026-10-26 categories: column author: 松塚 canonical: https://www.liberogic.jp/topics/20261026-supabase-apps-cloudflare2/ --- # Supabase AuthとCloudflareで認証付きWebアプリを作る ![](https://images.microcms-assets.io/assets/4b13731f29254025b91c8d846198ffc9/0eb4481600af4247b0b2191a27a869cb/cover.png) Supabase AuthとCloudflareを組み合わせた認証付きWebアプリの構築方法：ログイン認証や権限管理、RLSによるデータアクセス制御、Cloudflareを活用した多層的なセキュリティ対策について紹介します。 はじめまして、リベロジックのまっつんです。 今回初めて記事を書きます。 PHP2ShellからHTTP2Shellなどセキュリティのニュースが続いていますね。 CloudflareもPHPの脆弱性に対するWAF対策を発表しています。 これからはWebシステムだけでなくスタッフのPCやネットワーク環境にも、もっと意識を向ける必要があると感じています。 先日CTOの大塚が[SupabaseとCloudflareで専用Webアプリを作っている件](https://www.liberogic.jp/topics/supabase-apps-cloudflare1/)を書いていました。 今回はその続きとして、私から業務アプリに欠かせない**「認証」**の話をします。 社内システムや取引先向けポータルでは、ログインできるだけでは不十分です。利用者によって見られる情報や使える機能を分ける必要があります。そこで使っているのが**Supabase Auth**です。 ## 業務アプリではだいたいログインが必要になる - 社内申請・承認システム - 会員向けマイページ - 取引先向けポータル - 工数・勤怠管理 - 案件管理 - 店舗・拠点向け管理システム こうしたWebアプリでは、ほとんどの場合ログイン機能が必要になります。 ただし「IDとパスワードを入力してログインできる」だけでは不十分です。 例えば社内申請システムなら、 - 一般社員 - 上長 - 拠点管理者 - 本部管理者 - システム管理者 など同じアプリを使っていても立場によってできることが違います。 取引先向けポータルならA社の担当者がB社の情報を見られては困ります。 認証付きWebアプリでは、 - **「誰なのか」を確認する認証** - **「その人が何をしていいのか」を決める権限管理** を分けて考える必要があります。 ## 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 ` ``` は管理者だけといったようにURL単位でもアクセスを制御します。 単純に画面上の「管理」ボタンを非表示にしただけではセキュリティにはなりません。 URLを直接開いたり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と権限制御を組み合わせて利用できます。 ## 認証基盤を全部自作しなくてよくなった 以前であれば、認証付きの業務システムを作ろうとすると、認証サーバーをどうするか、セッションをどう管理するか、データベースとどう紐づけるか、といったところから設計する必要がありました。 もちろん現在でも設計そのものは必要です。 ただSupabase Authのような仕組みを使うことで、認証基盤をゼロから構築する作業を減らせます。その分、 - **誰に何を見せるのか** - **誰に何を操作させるのか** - **業務上どういう権限が必要なのか** という本来考えるべきところに時間を使えるようになります。 個人的には、このあたりがSupabaseを業務アプリで使う大きなメリットだと思っています。 ## まとめ Supabase AuthとCloudflareを組み合わせることで比較的シンプルな構成でも認証付きWebアプリを作ることができます。 ただし大事なのはログイン画面を作ることではありません。 認証されたユーザーに対して、 - 何を見せるのか - 何を操作できるのか - どのデータにアクセスできるのか まで設計して、初めて業務で使えるWebアプリになります。 Supabase Authは「誰なのか」を確認するところを担当し、その先の権限制御をアプリケーションやデータベース側で組み立てていくイメージです。 次回は**SupabaseのRLSを業務アプリでどう使うか**を書いてみます。