コンテンツにスキップ
非エンジニアのためのVibeCoding入門

認証の実装方法を選ぶ

この章でわかること: Basic 認証では足りない、利用者ごとの アカウントを持つ本格的なログインをどう実装するか。大きく2つの路線があります。 ここでは、特定のインフラに縛られにくい Auth.js + データベース認証を推奨として、 選び方を整理します。

前提:2種類の「認証」を区別する

Section titled “前提:2種類の「認証」を区別する”

同じ「ログイン」でも、レベルが違います。混同すると設計を誤ります。

  • 簡易な目隠し(Basic認証): サイト全体に1つの合言葉。関係者デモ向け。 → Basic 認証で解説済み
  • 本格的な認証(この章): 利用者ごとにアカウントがあり、本人だけが自分の データを見られる。パスワード再発行や権限の出し分けもできる

「会員機能が要る」「人によって見えるものを変えたい」なら、後者が必要です。

2つの路線

Section titled “2つの路線”
路線代表例特徴
BaaS に寄せるSupabase Auth, Firebase Auth, Clerk など認証を丸ごと外部サービスに任せる。速いが、そのサービスに強く依存する
自前で持つ(推奨)Auth.js + 自分のデータベース認証ロジックを自分のアプリ側に置く。インフラを選ばない・移行しやすい

推奨:Auth.js + データベースの id/password 認証

Section titled “推奨:Auth.js + データベースの id/password 認証”

このサイトでは、Auth.js(旧 NextAuth.js)を使い、自分のデータベースに保存した ID とパスワードで認証する構成を基本の推奨とします。理由は一点、 インフラに依存しないからです。

  • 認証の状態(ユーザー、セッション)を自分のDBに持つので、Supabase でも Vercel Postgres でも Cloudflare D1 でも、つなぐ先を選ばない
  • デプロイ先(Vercel / Cloudflare など)を乗り換えても、認証の作りは基本そのまま
  • 「まず Supabase の Auth で作ったが、あとで別基盤に移りたい」で詰まる、という よくある落とし穴を避けられる
  • 後から Google ログインなどの外部連携(OAuth)を足すのも、Auth.js の同じ土台で拡張できる

Supabase 等の BaaS が向く場合もある

Section titled “Supabase 等の BaaS が向く場合もある”

推奨は自前ですが、BaaS が悪いわけではありません。次のような場合は素直に BaaS を選ぶのも手です。

  • とにかく今すぐ動かしたい、移行は当面考えない
  • Google / GitHub ログインだけで済み、パスワード管理を自分でしたくない
  • 認証以外(DB・ストレージ等)もまとめて1つのサービスに寄せたい

「速さ」を取るなら BaaS、「自由度と移行のしやすさ」を取るなら Auth.js + 自前DB。 プロトタイプの先で長く育てるつもりなら、後者が効いてきます。

なぜ大事か

Section titled “なぜ大事か”

認証は「あとで差し替える」のが最も重いパーツの一つです。最初にインフラ非依存の 路線(Auth.js + 自前DB)を選んでおけば、デプロイ先やサービスの都合に振り回されずに 機能を育てられます。速さが最優先の場面だけ BaaS を選ぶ——この判断軸を持っておきましょう。

参考リンク(情報ソース)

Section titled “参考リンク(情報ソース)”