Next.jsの認証方法を比較
Next.jsの認証：Auth.js、Better Auth、Clerkを比較 | We.Inc
Next.js 16向けに、Auth.js、Better Auth、Clerk、Supabase Auth、自作のセッションを比較します。それぞれのセットアップコードと、要件に合わせて候補を絞り込む選択ツールも用意しています。
Next.jsの認証方法を比較
ほとんどのNext.jsアプリでは、認証を自作するよりライブラリを選びましょう。Clerkはホスティング型で最も手早く導入でき、Supabase AuthはすでにSupabaseを使っているアプリに向いています。Better AuthやAuth.jsなら、ユーザーを自分のデータベースに保持できます。どれを選んでも、サーバー側のコードでもう一度セッションを確認してください。プロキシでの確認だけではデータは守れないからです。
ひと目でわかる比較
- Clerk
- Clerkのサーバー
- @clerk/nextjs、ClerkProvider、proxy.ts内のclerkMiddleware
- Supabase Auth
- 自分のSupabaseプロジェクト
- @supabase/ssrのクライアントと、セッションを更新するプロキシ
- Better Auth
- 自分のデータベース
- authインスタンスとapp/api/auth/[...all]/route.ts
- Auth.js（next-auth v5ベータ版）
- 自分のデータベースまたはJWTのCookie
- auth.tsとapp/api/auth/[...nextauth]/route.ts
- 自作する
- 自分のデータベース
- joseまたはiron-session、httpOnlyのCookie、データアクセス層
Next.jsの公式ガイドには対応する認証ライブラリが12個も挙げられており、ほとんどの人にとっては選択肢が多すぎます。この比較では、多くのチームが実際に検討する5つの方法に絞り、それぞれについてApp Routerでの最小限のコードを示します。さらに、どのライブラリでサインインさせる場合でも、アプリ側で必ず行うべき確認についても説明します。
- ユーザーデータを自分のデータベースに保持する、既製のサインイン画面を使うなど、自分にとって重要な要件にチェックを入れます。
- 選択ツールは、チェックしたすべての要件を満たさない選択肢を非表示にします。
- 残った選択肢のセットアップコードを開き、自分で書く量を比較します。
- どの選択肢を選ぶ場合も、公開前にセキュリティのセクションを読みましょう。
- Next.jsのガイドが推奨するとおり、セッションはHttpOnly、Secure、SameSite、有効期限を指定してサーバー側で設定したCookieに保存しましょう。
- verifySession()関数をサーバー専用の1つのファイルにまとめ、ページ、Server Actions、Route Handlerから呼び出しましょう。
- 認証チェックをレイアウトに頼ってはいけません。レイアウトはクライアント側の画面遷移では再レンダリングされないため、チェックが飛ばされることがあります。
- セッションのデータは小さく保ちましょう。ユーザーIDとロールだけにし、メールアドレスや電話番号は決して含めないでください。
- シークレットはopenssl rand -base64 32（Auth.jsならnpx auth secret）で生成し、環境変数で管理しましょう。
よくある質問
NextAuthはまだメンテナンスされていますか？
以前NextAuthと呼ばれていたAuth.jsは、現在はBetter Authの一部になったと自身のサイトで述べています。Next.js向けのインストールコマンドは引き続きnpm install next-auth@betaです。新規プロジェクトは最初からBetter Authで始めることが多く、既存のAuth.jsのアプリはそのまま動作します。
proxy.tsだけでページを保護できますか？
いいえ。Next.jsのドキュメントでは、プロキシでの確認は楽観的なチェックとされています。Cookieに基づく素早いリダイレクトには適していますが、セキュリティの境界にはなりません。Server Functionsやマッチャーの対象外のルートはプロキシを通らないため、データに近い場所で改めてセッションを検証しましょう。
最も安い選択肢はどれですか？
Better AuthやAuth.jsのように自分のデータベースにユーザーを保存するライブラリには、ユーザーごとの料金がかかりません。費用はデータベースとメール送信の分だけです。2026年10月時点で、Supabase Authの無料プランには月間アクティブユーザー50,000人分が含まれています。Clerkの現在の無料枠は、同社の料金ページで確認してください。
これらはNext.js 16で動作しますか？
はい。ClerkとSupabaseはどちらも、Next.js 16向けにはproxy.ts、それ以前のバージョン向けにはmiddleware.tsの使い方を公式に説明しています。Better Authは、プロキシ用のCookieヘルパーと、サーバー側コード用の完全なセッション確認を提供しています。
ステートレスとデータベースセッション、どちらがよいですか？
署名付きCookie（ステートレス）はシンプルで照会も不要ですが、有効期限が切れる前に無効化できません。データベースセッションは確認のたびにクエリが1回かかりますが、ユーザーがすべての端末から一括でサインアウトできます。多くのライブラリでは、どちらにするかを選べます。
ホスティング型とセルフホスト型
- Clerkはユーザーの保存、サインインページ、セッション管理を代わりに運用してくれ、開発者はそのコンポーネントをレイアウトに組み込むだけです。ある程度の自由度と、規模が大きくなったときの月額料金と引き換えに、初日から速さと洗練されたUIが手に入ります。
- Better AuthとAuth.jsはアプリの中で動作し、自分のデータベースに書き込みます。データと画面は自分のものになりますが、メール配信、パスワード再設定のフロー、アップグレードも自分で担うことになります。
すでにSupabaseを使っている場合
- Supabase AuthはサインインをPostgresの行レベルセキュリティに直接結び付けるため、auth.uid() = user_idのようなポリシーでデータベース層のデータを保護できます。@supabase/ssrパッケージはセッションをCookieに保存するので、Server Componentsから読み取れます。
- Supabaseのドキュメントは、getSession()が検証されていないデータを返すと警告しています。ユーザーが誰かを信頼する前に、トークンの署名を確認するgetClaims()か、認証サーバーに問い合わせるgetUser()を使いましょう。
自作する場合
- Next.jsのガイドでは、フォームにServer Action、バリデーションにZod、ハッシュ化にbcrypt、7日間有効なセッションCookieの署名にjoseを使う手順が解説されています。仕組みの各部分を学ぶには良い方法です。
- 本番環境については、同じガイドがライブラリの利用を推奨しています。レート制限、メール認証、アカウント連携、多要素認証などを加えていくと、すぐに作業量が膨らむからです。
各選択肢の最小限のセットアップ
Clerk
@clerk/nextjsをインストールし、NEXT_PUBLIC_CLERK_PUBLISHABLE_KEYとCLERK_SECRET_KEYを設定します。Next.js 16では、ミドルウェアのファイルはproxy.tsです。
Supabase Auth
公開可能キーを使い、リクエストごとにCookieストアからサーバー用クライアントを作成します。getClaims()は、信頼する前にトークンを検証します。
Better Auth
キャッチオールのルートにハンドラーをマウントし、サーバー側でリクエストヘッダーを使ってセッションを読み取ります。
Auth.js（next-auth v5ベータ版）
auth.tsはhandlers、auth、signIn、signOutをエクスポートします。AUTH_SECRETを設定してください（npx auth secretで作成できます）。
自作の署名付きセッションCookie
Next.jsのガイドにあるパターンの短縮版です。joseがデータに署名し、CookieはHttpOnly、Secure、SameSite=Laxです。
セッションを確認する場所
場所ごとの認証チェック（Next.jsの認証ガイドより）
- 楽観的、Cookieのみ
- 素早いリダイレクト。レンダリング前に実行され、プリフェッチ時にも動く
- データアクセス層
- 安全
- すべてのデータ読み取りが1つのverifySession()を通る
- Server Actions
- 安全
- 公開エンドポイントと同様に扱い、変更前にロールを確認
- Route Handler
- 安全
- 未サインインなら401、ロールが違えば403
- レイアウト
- 避ける
- 画面遷移で再レンダリングされないため、チェックが飛ばされうる
Clerk
動作するサインインページまで最短。ユーザーはClerk側に保存されます。
Supabase Auth
ユーザーは自分のSupabaseのPostgresに保存されます。有料プランでは、含まれる人数を超えたユーザーに追加料金がかかります。
Better Auth
アプリ内のライブラリで、自分のデータベースに書き込みます。追加機能はプラグインで提供されます。
長く使われてきた選択肢で、現在はBetter Authの一部です。v5はまだベータ版として公開されています。
自作する
完全に自由に制御できます。すべてのフローを自分で書き、安全に保つ必要があります。
ユーザーの記録を自分が管理するデータベースに保持する
既製のサインイン画面とプロフィール画面
認証サービスからのユーザーごとの料金がない
サインインがPostgresの行レベルセキュリティと連携する
認証方法の選択ツール
重要な要件にチェックを入れると、そのすべてを満たす選択肢だけが一覧に残ります。
要件
チェックしたすべての要件を満たす選択肢はありません。1つ外して比較してください。
無料で始める · クレジットカード不要
関連: ガイド｜Webマーケティングと集客を学ぶ
製品
ご利用いただける方
機能
リソース
会社情報
サイトマップを見る