Server-Side Auth With @supabase/ssr

Cookies instead of localStorage

Server-rendered apps need the session on the server, so @supabase/ssr stores it in cookies. createBrowserClient is used in client components; createServerClient is used in server components, route handlers and middleware, with getAll/setAll cookie callbacks for your framework. Middleware typically refreshes the session on each request. On the server, trust auth.getUser() (or the newer claims verification in the docs) rather than reading the session from cookies unchecked, since cookies can be tampered with.

A server client in Next.js

App Router, @supabase/ssr (check the docs for your version).

import { createServerClient } from '@supabase/ssr'
import { cookies } from 'next/headers'

export async function createClient() {
  const cookieStore = await cookies()
  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll()
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value, options }) =>
            cookieStore.set(name, value, options)
          )
        },
      },
    }
  )
}

// in a server component
// const supabase = await createClient()
// const { data: { user } } = await supabase.auth.getUser()

Do not create one server client for all users

Server clients carry the current user's cookies, so create a fresh one per request; a shared module-level server client can leak sessions between users.

त्वरित जाँच: Where does @supabase/ssr keep the session?

• Only in localStorage
• In cookies, readable by the server
• In the database URL
• In environment variables