【ITニュース解説】Next.js + Supabase Auth Cookies: 6 Checks That Stop Silent Logouts

Next.jsとSupabaseを使って開発されたアプリケーションが、開発環境ではスムーズに動作するのに、本番環境にデプロイするとユーザーが突然ログアウトしてしまう「サイレントログアウト」という現象に遭遇することがある。これはユーザー体験を大きく損ねる問題であり、AIによって生成されたNext.jsアプリで特に見られやすい。この問題の多くは、SupabaseやNext.jsそのものの不具合ではなく、クッキーの設定ミス、ミドルウェアでのセッション更新不足、あるいは開発環境と本番環境の設定の不一致に起因する。本番デプロイを行う前に確認すべき重要な6つのチェック項目を解説する。

まず、クッキーのドメインを実際のホストと一致させる必要がある。クッキーはウェブサイトがユーザーのブラウザに保存する小さな情報で、主にセッション（ログイン状態など）を維持するために使われる。もしアプリケーションが app.example.com というドメインで稼働している場合、認証用のクッキーのドメインもこのホストをカバーするように設定しなければならない。開発中に localhost 用に設定されたクッキーや、サブドメインではなくルートドメイン (example.com) に設定されたクッキーは、本番環境では正しく機能せず、ユーザーが突然ログアウトしたように見える原因となる。また、プレビュー環境（テスト用の仮公開環境）の設定が誤って本番環境のクッキー設定を上書きしてしまうことがないよう注意が必要だ。サブドメインを使用している場合は、ルートドメインの前にピリオドをつけた形式（例: .example.com）でクッキーを設定することで、そのルートドメイン以下のすべてのサブドメインでクッキーが共有されるようにする必要があるかどうかも確認すると良いだろう。

次に、Secure属性とSameSite属性を正しく使用することが重要である。本番環境のウェブサイトは通常HTTPS（暗号化された安全な通信）で運用されるため、クッキーには必ずSecure属性を設定する必要がある。これにより、クッキーはHTTPS接続でのみ送信されるようになり、通信の盗聴による情報漏洩を防ぐ。また、SameSite属性は、クッキーがクロスサイトリクエスト（異なるドメインからのリクエスト）でどのように送信されるかを制御するもので、一般的には SameSite=Lax を設定することが推奨される。これは、標準的なサーバーレンダリングによる認証フローで安全性を高める設定である。開発環境ではHTTP（非暗号化通信）で動くためSecure属性がなくても問題なく動くが、本番環境のHTTPSではSecure属性が必須となる。また、OAuth認証フローのように、一度別のサイト（認証プロバイダ）にリダイレクトされ、その後アプリケーションに戻ってくる際に、SameSite属性の誤った設定（特に SameSite=Strict や、一部ブラウザのデフォルトである SameSite=Lax との挙動の不一致）が原因でセッションが失われることがあるため注意が必要だ。

三番目に、ミドルウェアとブラウザクライアントを同じSupabaseプロジェクトに紐付けるべきである。Supabaseを使用する際、開発環境と本番環境でそれぞれ異なるSupabaseプロジェクト（データやユーザー情報が保存される場所）を使うのが一般的だ。それぞれの環境で、NEXT_PUBLIC_SUPABASE_URL や匿名キーといったSupabaseのAPIキーが、対応するプロジェクトのものと一致しているか確認する必要がある。もしプレビュー環境のキーが本番環境のアプリに設定されているなど、環境間でキーが混ざってしまうと、ユーザーがログインしているはずなのに本番環境ではセッションが空っぽに見えるという、不安定な認証のバグを引き起こす。また、Supabaseのサービスロールキーは非常に強力な権限を持つため、これをブラウザに公開することは絶対に避け、サーバーサイドでのみ使用するべきである。ミドルウェアで認証を処理する際は、クッキーを扱えるサーバーサイドのSupabaseクライアントを使うようにしよう。

四番目に、ページ読み込み時だけでなく、ミドルウェアでもセッションを更新することが肝要である。認証セッションには有効期限があるため、ユーザーが長時間タブを開いたままにしておくと、そのタブのセッションが期限切れになることがある。もしミドルウェア（リクエストが最終的なページに到達する前に実行される処理）でセッションクッキーの更新が行われない場合、ユーザーが次にページを操作しようとした時に突然ログアウトしたように見える。特に「昨日までは動いたのに」という報告の多くは、ユーザーが一晩中タブを開きっぱなしにしていたことが原因である。ミドルウェアやプロキシといったエッジ（ユーザーからのリクエストを最初に受け取る部分）でセッションを更新することで、ページがレンダリングされる前にトークン（認証情報を一時的に保持するもの）を常に最新の状態に保つ機会が生まれ、セッション切れによる不意のログアウトを防ぐことができる。

五番目に、Supabase Authの許可リストにリダイレクトURLをすべて登録する必要がある。Supabase Authサービスを利用してユーザー認証を行う際、OAuth認証プロバイダ（GoogleやGitHubなど）やマジックリンク（メールで送られるログインリンク）からの認証が完了した後、ユーザーをアプリケーション内の特定のURLにリダイレクトする。これらのリダイレクト先のURLは、Supabaseの認証設定で事前に許可リストとして登録しておかなければならない。もし登録されていないURLへのリダイレクトが発生した場合、認証後にエラーになったり、セッション情報が正しく渡されずにログアウト状態になったりする。Vercelなどのデプロイサービスではプレビュー環境のURLが頻繁に変わるため、プランで許可されている場合はワイルドカードパターン（例: *.vercel.app）を使用するか、安定したプレビュー用ドメインを設定することを検討しよう。また、Supabase Auth設定内の「サイトURL」が本番環境のドメインと一致しているか、古いステージング環境のURLが残っていないかも確認が必要である。

最後に、パスワード変更後に二つの異なるブラウザでテストすることが、セキュリティ上も非常に重要である。ユーザーがパスワードを変更した際、それまでログインしていた他のすべてのセッション（例えば、別のコンピューターや別のブラウザでログインしていた状態）が正しく無効化されるかを確認する。ここで予期しない挙動が見られる場合、それは単なるユーザー体験の不具合ではなく、深刻なセキュリティ上の脆弱性である可能性がある。ソーシャルログイン（GoogleやGitHubなど）を提供している場合は、OAuth認証でリンクされたアカウントでも同様にテストを行い、期待通りにセッションが無効化されることを確認しよう。

これらの基本的なチェックポイントに加え、ミドルウェアでマーケティングページ、ログインページ、認証コールバックURL、ヘルスチェックなどの公開ルートが、誤って認証済みのセッションを強制するゲートを通らないように設定することも重要だ。AIによって生成されたアプリでは、しばしばルートパス / などが過剰に保護され、ログインループのような問題を引き起こすことがあるため注意が必要である。

本番環境にデプロイする前の迅速な確認として、以下の手順を推奨する。まず、本番URLでシークレットモードのブラウザを開き、サインインする。次に、ハードリフレッシュを何度か行い、認証が必要なルートを三つほどナビゲートしてみる。その後、同じアカウントで別のブラウザを開き、パスワードを変更し、最初のブラウザのセッションがどのように変化するか（期待通りにログアウトされるかなど）を確認する。普段使っているプレビューURLからマジックリンクをトリガーし、正しく認証されるかを確認する。最後に、ミドルウェア処理後のドキュメントレスポンスで Set-Cookie ヘッダーが送信されているかをブラウザの開発者ツールの「ネットワーク」タブで確認する。これら五つのチェックがすべてパスすれば、サイレントログアウトの問題がクッキー関連である可能性は低いと言えるだろう。

これらの確認作業を通じて、アプリケーションはより堅牢になり、ユーザーは安心してサービスを利用できるようになる。