📘

Next.js14 + Supabase　セッション　トークン　クッキー　ソケット　購読

に公開
Next.js
auth
session
subscription
Supabase
tech

ひとことで要約

  • セッション：ログイン中の継続状態
  • トークン：その状態を証明する鍵（JWT など）
  • クッキー：鍵を安全に運ぶ箱（HttpOnly が鉄則）
  • ソケット：双方向の常時回線
  • 購読：イベントを受け取り続ける登録（解除必須）

用語のざっくり整理

  • セッション (session)
    「今このユーザーはログイン中だよね？」という継続中の状態。

    • 方式1: サーバー管理型（サーバーに状態を保存、クッキーにはIDだけ）
    • 方式2: トークン型（状態は保存せず、JWT 等のトークンが「ログイン中」を証明）
      Supabase は後者で、session オブジェクト＝access_token + refresh_token の束を意味します。

  • トークン (token)
    サーバーに「私は誰で、何が許されるか」を伝える署名付きの文字列。

    • Access Token（短命）：API 呼び出しに付ける。期限切れしやすい。
    • Refresh Token（長命）：Access を再発行するためだけに使う。
    • JWT or Opaque：中身を読める（JWT）/読めない（Opaque）。Supabase は JWT。

  • クッキー (cookie)
    ブラウザが自動で送る小さな保存領域。

    • 認証では HttpOnly + Secure + SameSite を強く推奨（XSS/CSRF対策）。
    • サーバー側レンダリング（SSR）と相性が良い（ヘッダで取れるため）。

  • ソケット (socket / WebSocket)
    ブラウザとサーバーの双方向・常時接続。

    • 例：チャット、通知、リアルタイムメーター。
    • HTTP とは別の常時張りっぱなしの回線。切断/再接続処理が要る。

  • 購読 (subscription / subscribe)
    「このイベントが起きたら知らせて」の受け取り登録。

    • 例：DB変更、メッセージ到着、GraphQL Subscriptions、RxJS の observable.subscribe()。
    • 実体は WebSocket / SSE / Supabase Realtime / Pusher 等。
    • 解除 (unsubscribe) を忘れない。

どう組み合わせる？（典型フロー）

  1. ユーザーがログイン
  2. サーバー/SDKが access_token と refresh_token を取得
  3. それらを HttpOnly クッキーに保存（SSR で読める）
  4. API 呼び出し時は access_token を Authorization ヘッダで送る
  5. 期限切れ→ refresh_token で自動再発行
  6. 画面のリアルタイム更新は ソケットで購読（DB変更イベントなど）

Next.js + Supabase（@supabase/ssr）の最小実装パターン

1) サーバークライアント（非推奨オーバーロード回避版）

// app/utils/supabase/server.ts
import { cookies } from 'next/headers'
import { createServerClient, type CookieOptions } from '@supabase/ssr'

export function createSupabaseServer() {
  const cookieStore = cookies() // Next.js のサーバー側クッキー
  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        get(name: string) {
          return cookieStore.get(name)?.value
        },
        set(name: string, value: string, options: CookieOptions) {
          cookieStore.set({ name, value, ...options }) // HttpOnly/SameSite 等は SDK が付与
        },
        remove(name: string, options: CookieOptions) {
          cookieStore.set({ name, value: '', ...options })
        },
      },
    }
  )
}
  • これが 現行の推奨形。cookies: { get/set/remove } を渡すオーバーロードにすると、取り消し線（deprecated）を避けられます。
  • SSR で await createSupabaseServer().auth.getUser() のように利用。

2) ブラウザクライアント

// app/utils/supabase/client.ts
import { createBrowserClient } from '@supabase/ssr'

export const supabase = createBrowserClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
)

3) ログイン/ログアウト（例）

// app/(auth)/login/actions.ts
'use server'
import { createSupabaseServer } from '@/app/utils/supabase/server'

export async function login(email: string, password: string) {
  const supabase = createSupabaseServer()
  const { error } = await supabase.auth.signInWithPassword({ email, password })
  if (error) throw error // クッキーは SDK が自動で更新
}

Supabase Realtime（DB変更の購読）

// e.g. app/member/messages/realtime.ts
'use client'
import { supabase } from '@/app/utils/supabase/client'
import { useEffect } from 'react'

export function useMessagesRealtime() {
  useEffect(() => {
    const channel = supabase
      .channel('public:messages')
      .on(
        'postgres_changes',
        { event: '*', schema: 'public', table: 'messages' },
        (payload) => {
          // 追加/更新/削除イベントをハンドル
          console.log('change:', payload)
        }
      )
      .subscribe()

    return () => {
      supabase.removeChannel(channel) // ★購読解除を忘れずに
    }
  }, [])
}
  • 裏側は WebSocket。接続エラー時の再接続は SDK が面倒見ます。
  • 認可は RLS + JWT の claims で制御されます。

何をいつ使う？

  • API 認証を SSR/CSR 両方で安全に → トークンを HttpOnly クッキーで管理（@supabase/ssr）
  • リアルタイム UI（チャット/通知/カウンター） → ソケット + 購読
  • 単発のデータ取得（一覧/詳細） → 通常の HTTP フェッチ（必要なら ISR/SSR）
  • 長時間の処理進捗を追う → まずは HTTP + ポーリング、頻度/負荷次第で ソケットへ

セキュリティの要点（超重要）

  • クッキーは HttpOnly + Secure + SameSite=Lax/Strict（XSS/CSRF対策の基本）
  • トークンは localStorage に保存しない（XSS 全取得のリスク）
  • 短命な Access / 長命な Refresh の分離（漏洩時リスク低減）
  • **RLS（行レベルセキュリティ）**で DB 側も縛る（auth.uid() = user_id だけでなく、用途別に最小権限）
  • ソケット接続にも認証（接続時にトークンを送る / SDK に任せる）

よくある混同の解消

  • セッション ≠ クッキー
    セッションは「状態の概念」、クッキーは「保存/送信の箱」。
  • セッション ≒ トークン束（トークン型の場合）
    Supabase の session は実態が「Access/Refresh トークンのセット」。
  • 購読はプロトコルではない
    購読は「パターン」。実装は WebSocket/SSE/Realtime/GraphQL など様々。

Discussion