Supabase (Authentication System)

Supabase can be used as an Authentication System in WeWeb. This is a good choice if your app already uses Supabase for data, or if you want a hosted authentication solution.

What this system supports

• Sign in methods provided by Supabase Auth (email/password, magic links, and OAuth providers configured in Supabase)
• Sessions managed by Supabase
• User display and basic user management inside WeWeb

Set up Supabase

1) Create a Supabase connection

1. Go to Data & API → Authentication.
2. • A) If this is your first time opening the Authentication area, choose Supabase when prompted.
   • B) If this is not your first time, open Configuration, click Switch authentication system, then select Supabase.
3. When asked for a Connection, create or select a Supabase connection for the current environment.

In the connection setup, WeWeb stores the Supabase values as environment variables (so you can use different projects per environment).

2) Fill in the connection fields

In the Supabase connection, you’ll typically set:

• Access token
• Refresh token
• Project (Project reference)
• Branch (Optional; default is the main project)
• Publishable key
• Secret key
• Custom domain (Optional)

Test sign in

1. In the Interface tab, create a login flow using Supabase authentication actions.
2. Preview and sign in with a test account.
3. Confirm the user is authenticated and that protected pages/endpoints behave as expected.

For page and API protection, see Users and roles →.

Common pitfalls

It works in one environment but not another

Make sure each environment has the correct Supabase project selected and keys saved.

Email sign up does not work for external users

Supabase can restrict auth emails until you configure an email provider (SMTP) in Supabase. If sign up emails are not being delivered, check your Supabase Auth email settings.

Expecting database roles on the signed-in user object

The Authentication System does not merge custom role rows onto the Supabase auth user exposed in the interface. Load roles via a workflow into your own variable and bind to that instead. See Using custom roles in the interface.

1) Add a profiles table in Supabase

Create a table that stores custom data per user.

For example, a profiles table might include:

• user_id — Matches auth.users.id
• role — Your app role (for example user, admin)
• Other columns as needed (display name, settings, and so on)

2) Create a profile row when a user signs up

Use a trigger on auth.users so every new Supabase Auth user gets a matching row in public.profiles. Example SQL for trigger cration:

drop trigger if exists on_auth_user_created on auth.users;
drop function if exists public.handle_new_user();

create or replace function public.handle_new_user()
returns trigger
language plpgsql
security definer
set search_path = public
as $$
begin
  insert into public.profiles (
    id,
    user_id,
    role
  )
  values (
    gen_random_uuid(),
    NEW.id,
    'user'
  );

  return NEW;
end;
$$;

create trigger on_auth_user_created
after insert on auth.users
for each row
execute procedure public.handle_new_user();

TIP

security definer lets the trigger insert into public.profiles even when the signing-up user cannot. Keep policies on profiles tight so ordinary clients only see their own row.

3) Load the current user’s profile in WeWeb

Use workflows to fetch that row and keep it somewhere the interface can read (often a global variable).

1. Add a variable to hold the profile (for example an object or individual fields such as role name).

2. Add a Supabase → Select action (Database | Select →) that reads from profiles.

3. Add a filter so user_id equals the signed-in user’s id (use the auth / current user id from the binding panel for your project).

4. After a successful fetch, store the row (or fields you need) into your variable.

5. Wire conditions and bindings to that variable.

Reference

Connection fields

Field	Description	Where to find it
Access token	Token used to access your Supabase account	Supabase account settings
Refresh token	Token used to refresh the access token	Supabase account settings
Project	The Supabase project to use	Supabase dashboard
Branch	Project branch reference (if using branching)	Supabase dashboard
Publishable key	Public API key used by the app	Supabase dashboard (API keys)
Secret key	Secret API key	Supabase dashboard (API keys / secrets)
Custom domain	Custom API domain (optional)	Supabase custom domains

Frequently asked questions

Why are my custom Supabase roles not on the current user in bindings?

The Authentication System keeps the interface user object aligned with Supabase auth. Fields like an app role belong in your own tables (for example profiles.role) and should be loaded with a workflow into a variable. See Using custom roles in the interface.

What is the difference between Supabase’s role field and profiles.role?

Supabase’s role on the auth user (for example authenticated) comes from the auth session. Your profiles.role (or similar column) is application data you define and query yourself.

Where is the legacy Supabase Auth plugin documented?

The older flow is documented under Supabase authentication (legacy plugin) →. Use this page for Data & API → Authentication with Supabase.

CONTINUE LEARNING

Use roles consistently across the interface and backend.

Users and roles →