Setting Up Role-Based Access Control (RBAC) with Supabase Auth

RBAC (Role-Based Access Control) is the foundation of any B2B SaaS. Yet many developers hard-code roles in the frontend — a major security flaw. Here is the clean method with Supabase Auth and Next.js.

1. Data model

Roles should not live on the user but on the membership between a user and an organization:

memberships (
  user_id uuid references auth.users,
  account_id uuid references accounts,
  role_slug text references roles(slug)
)

The same user can be owner in one organization and member in another. The role only makes sense within an account context.

2. Dynamic or fixed roles?

Two approaches exist:

• Hard-coded: 3 roles max (owner, admin, member). Simple but not extensible.
• Dynamic in DB: roles table with a permissions column (JSONB). Lets admins create custom roles from the UI.

For a serious B2B SaaS, choose the dynamic version with protected system roles.

3. Row Level Security (RLS)

Security must be enforced at the database layer, not just the application:

CREATE POLICY "members_can_read" ON projects FOR SELECT
USING (EXISTS (
  SELECT 1 FROM memberships
  WHERE memberships.account_id = projects.account_id
  AND memberships.user_id = auth.uid()
));

4. Server-side permission checks

Build a checkPermission(accountId, permission) helper that:

1. Loads the user's membership
2. Loads the linked role
3. Checks if the role grants the requested permission

Call it in every API route and server action before any sensitive action.

5. Conditional UI

On the client, hide buttons based on permissions. But never rely on UI for security — users can always call the API directly.

Conclusion

A robust RBAC is non-negotiable for a B2B SaaS. Get it right from day one. Boilerplate-Stack gives you the full architecture, tested and documented.