How to Test Supabase Auth End to End: Complete 2026 Guide

This is your baseline smoke test. If email/password authentication breaks, every other auth method is suspect. The scenario covers both sign-up (new user) and sign-in (existing user), and it verifies the user lands on a protected page after authentication.

Goal

Create a new account with email and password, confirm the user is redirected to the dashboard, sign out, then sign back in with the same credentials and verify the dashboard loads again.

Playwright Implementation

Assrt Equivalent

# scenarios/supabase-email-auth.assrt
describe: Email/password sign-in with Supabase

given:
  - a test user exists with email "e2e@test.local" and password "TestPassword123!"
  - I am on the login page

steps:
  - fill the email field with "e2e@test.local"
  - fill the password field with "TestPassword123!"
  - click "Sign in"

expect:
  - I am redirected to /dashboard within 10 seconds
  - the page shows a "Dashboard" heading

Magic link login is the scenario most teams skip because they do not know how to intercept the email. With the local Supabase stack, every email routes to Inbucket, which exposes a REST API for programmatic retrieval. The test flow is: request the magic link, poll Inbucket for the email, extract the confirmation URL, navigate to it, and verify the user is authenticated.

Key Challenge: PKCE Code Verifier

Supabase uses PKCE for magic link flows. When the browser requests the magic link, the Supabase client stores a code_verifier in local storage. When the user clicks the magic link, the callback page reads that verifier to complete the token exchange. If your test opens the magic link in a new browser context (or a different page without the stored verifier), the exchange will fail with a "code challenge does not match" error. You must open the magic link in the same browser context that requested it.

Playwright vs Assrt

import { test, expect } from '@playwright/test';
import { extractConfirmationUrl } from './helpers/inbucket';

test('magic link login via Inbucket', async ({ page }) => {
  const mailbox = `magiclink+${Date.now()}`;
  const email = `${mailbox}@test.local`;

  // 1. Navigate to login and request a magic link
  await page.goto('/auth/login');
  await page.getByRole('tab', { name: /magic link/i }).click();
  await page.getByLabel('Email').fill(email);
  await page.getByRole('button', { name: /send magic link/i }).click();

  // 2. Wait for confirmation message in UI
  await expect(page.getByText(/check your email/i)).toBeVisible();

  // 3. Poll Inbucket for the email (retry because delivery is async)
  let confirmUrl: string = '';
  await expect(async () => {
    confirmUrl = await extractConfirmationUrl(mailbox);
    expect(confirmUrl).toBeTruthy();
  }).toPass({ timeout: 10_000 });

  // 4. Open the magic link in the SAME page (preserves PKCE verifier)
  await page.goto(confirmUrl);

  // 5. Supabase processes the token exchange and redirects
  await page.waitForURL(/\/dashboard/, { timeout: 15_000 });
  await expect(page.getByRole('heading', { name: /dashboard/i }))
    .toBeVisible();
});

OAuth through Supabase involves three redirects: your app redirects to Supabase Auth, Supabase redirects to the OAuth provider (Google, GitHub, etc.), and the provider redirects back to Supabase, which then redirects to your app with session tokens. Testing this end-to-end against a real provider in CI is fragile because the provider login pages change frequently and require real credentials. The recommended approach is to test two things separately: that the initial redirect lands on the correct provider URL, and that the callback handler works when given a valid authorization code.

Testing the Redirect (Without Real Provider Credentials)

import { test, expect } from '@playwright/test';

test('GitHub OAuth redirects to correct authorize URL', async ({ page }) => {
  await page.goto('/auth/login');

  // Intercept navigation to capture the redirect URL
  const [request] = await Promise.all([
    page.waitForRequest(req =>
      req.url().includes('github.com/login/oauth/authorize')
    ),
    page.getByRole('button', { name: /continue with github/i }).click(),
  ]);

  const url = new URL(request.url());
  // Verify the OAuth params are correct
  expect(url.searchParams.get('client_id')).toBeTruthy();
  expect(url.searchParams.get('redirect_uri')).toContain(
    'supabase.co/auth/v1/callback'
  );
  expect(url.searchParams.get('scope')).toContain('user:email');
});

test('Google OAuth redirects to correct authorize URL', async ({ page }) => {
  await page.goto('/auth/login');

  const [request] = await Promise.all([
    page.waitForRequest(req =>
      req.url().includes('accounts.google.com/o/oauth2')
    ),
    page.getByRole('button', { name: /continue with google/i }).click(),
  ]);

  const url = new URL(request.url());
  expect(url.searchParams.get('client_id')).toBeTruthy();
  expect(url.searchParams.get('redirect_uri')).toContain(
    'supabase.co/auth/v1/callback'
  );
});

Testing the Callback Handler

To test the callback side without real provider credentials, use the Supabase Admin API to create a user with a specific provider identity, then simulate the session by setting the tokens directly. This avoids the fragile middle step of automating a third-party login page.

import { test, expect } from '@playwright/test';
import { createClient } from '@supabase/supabase-js';

test('OAuth callback sets session and redirects to dashboard', async ({ page }) => {
  const supabaseAdmin = createClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY!
  );

  // Create a user that mimics an OAuth sign-in
  const { data } = await supabaseAdmin.auth.admin.createUser({
    email: `oauth+${Date.now()}@test.local`,
    email_confirm: true,
    app_metadata: { provider: 'github', providers: ['github'] },
    user_metadata: { avatar_url: 'https://example.com/avatar.png' },
  });

  // Generate a session for this user
  const { data: session } = await supabaseAdmin.auth.admin
    .generateLink({ type: 'magiclink', email: data.user!.email! });

  // Navigate the callback URL with the token
  await page.goto(session.properties?.action_link || '/');
  await page.waitForURL(/\/dashboard/, { timeout: 15_000 });
  await expect(page.getByRole('heading', { name: /dashboard/i }))
    .toBeVisible();
});

Assrt Equivalent

# scenarios/supabase-oauth.assrt
describe: GitHub OAuth redirect points to the correct provider

given:
  - I am on the login page

steps:
  - click "Continue with GitHub"

expect:
  - the browser navigates to github.com/login/oauth/authorize
  - the redirect_uri parameter contains "supabase.co/auth/v1/callback"
  - the client_id parameter is present

Supabase supports phone-based authentication where a one-time password is sent via SMS. In production this goes through Twilio or another SMS provider, but in the local development stack you can configure a test phone provider that logs OTP codes to the Supabase logs. For CI, the most reliable approach is to use the Supabase Admin API to verify the OTP directly, or to read the OTP from the auth schema in PostgreSQL.

Playwright Implementation

import { test, expect } from '@playwright/test';
import { createClient } from '@supabase/supabase-js';
import { Pool } from 'pg';

// Connect to local Supabase Postgres to read OTP
const pool = new Pool({
  connectionString: 'postgresql://postgres:postgres@127.0.0.1:54322/postgres',
});

test('phone OTP sign-in', async ({ page }) => {
  const phone = '+15555550100';

  await page.goto('/auth/login');
  await page.getByRole('tab', { name: /phone/i }).click();
  await page.getByLabel('Phone number').fill(phone);
  await page.getByRole('button', { name: /send code/i }).click();

  await expect(page.getByText(/enter.*code/i)).toBeVisible();

  // Read the OTP directly from the local Supabase database
  const result = await pool.query(
    `SELECT phone_change_token FROM auth.users
     WHERE phone = $1
     ORDER BY updated_at DESC LIMIT 1`,
    [phone]
  );
  const otp = result.rows[0]?.phone_change_token || '000000';

  // Fill the OTP input
  await page.getByLabel('Verification code').fill(otp);
  await page.getByRole('button', { name: /verify/i }).click();

  await page.waitForURL(/\/dashboard/, { timeout: 10_000 });
  await expect(page.getByRole('heading', { name: /dashboard/i }))
    .toBeVisible();
});

Note: The exact column name for the OTP depends on your Supabase version and configuration. In some versions the token is stored in confirmation_token rather than phone_change_token. Check the auth.users table schema in your local instance.

Assrt Equivalent

# scenarios/supabase-phone-otp.assrt
describe: Phone OTP login using local Supabase

given:
  - I am on the login page
  - I use the phone tab

steps:
  - fill the phone number field with "+15555550100"
  - click "Send code"
  - wait for the verification code input to appear
  - retrieve the OTP from the local database for "+15555550100"
  - fill the verification code field with the OTP
  - click "Verify"

expect:
  - I am redirected to /dashboard within 10 seconds
  - the page shows a "Dashboard" heading

Row Level Security is what makes Supabase auth testing fundamentally different from testing other auth providers. With RLS enabled, a signed-in user can only read and write rows where the auth.uid() matches the row owner. This means your auth test is incomplete if it only verifies "user can log in." You also need to verify that User A cannot see User B's data, and that an unauthenticated request returns nothing.

Playwright Implementation

Assrt Equivalent

# scenarios/supabase-rls.assrt
describe: RLS prevents cross-user data access

given:
  - User A exists and has a todo titled "User A todo"
  - User B exists and has a todo titled "User B todo"
  - I am signed in as User A

steps:
  - navigate to /todos

expect:
  - I can see "User A todo"
  - I cannot see "User B todo"

Supabase access tokens have a short lifetime (default: 3600 seconds). The client library refreshes them automatically using the refresh token stored in local storage. If the refresh mechanism breaks, users get silently logged out after an hour. This is the kind of bug that never appears in manual testing because nobody sits on a page for an hour, but it will hit your users every day.

Playwright Implementation

import { test, expect } from '@playwright/test';
import { seedTestUser } from './helpers/seed-user';

test('session persists after page reload', async ({ page }) => {
  const email = `persist+${Date.now()}@test.local`;
  const password = 'TestPassword123!';
  await seedTestUser(email, password);

  // Sign in
  await page.goto('/auth/login');
  await page.getByLabel('Email').fill(email);
  await page.getByLabel('Password').fill(password);
  await page.getByRole('button', { name: /sign in/i }).click();
  await page.waitForURL(/\/dashboard/);

  // Verify session tokens exist in local storage
  const accessToken = await page.evaluate(() =>
    localStorage.getItem('sb-127-auth-token')
  );
  expect(accessToken).toBeTruthy();

  // Reload the page and verify the user is still authenticated
  await page.reload();
  await expect(page.getByRole('heading', { name: /dashboard/i }))
    .toBeVisible();
  // Should NOT be redirected to login
  await expect(page).not.toHaveURL(/\/auth\/login/);
});

test('token refresh works after expiry simulation', async ({ page }) => {
  const email = `refresh+${Date.now()}@test.local`;
  const password = 'TestPassword123!';
  await seedTestUser(email, password);

  await page.goto('/auth/login');
  await page.getByLabel('Email').fill(email);
  await page.getByLabel('Password').fill(password);
  await page.getByRole('button', { name: /sign in/i }).click();
  await page.waitForURL(/\/dashboard/);

  // Simulate token expiry by clearing only the access token
  // but leaving the refresh token intact
  await page.evaluate(() => {
    const stored = localStorage.getItem('sb-127-auth-token');
    if (stored) {
      const parsed = JSON.parse(stored);
      parsed.access_token = 'expired-token';
      parsed.expires_at = Math.floor(Date.now() / 1000) - 100;
      localStorage.setItem('sb-127-auth-token', JSON.stringify(parsed));
    }
  });

  // Trigger a navigation that requires auth
  await page.goto('/todos');

  // The Supabase client should auto-refresh using the refresh token
  // and the page should load without redirecting to login
  await expect(page.getByRole('heading', { name: /todos/i }))
    .toBeVisible({ timeout: 10_000 });
});

Assrt Equivalent

# scenarios/supabase-session-persistence.assrt
describe: Session persists across page reloads

given:
  - a test user exists
  - I am signed in to the dashboard

steps:
  - reload the page

expect:
  - I am still on /dashboard
  - I am NOT redirected to the login page
  - the dashboard heading is visible