Does WeWeb have built-in auth?

WeWeb does not have its own auth system — it integrates with external auth providers. The primary options are the native Supabase plugin (which handles email/password, magic link, and OAuth natively), the Auth0 plugin (for enterprise SSO), and a custom JWT plugin (for teams with an existing backend). For new projects, the Supabase plugin is the recommended path and covers 95% of use cases.

Can WeWeb use Supabase Auth?

Yes — WeWeb has a native Supabase plugin that integrates directly with Supabase Auth. It handles the full auth lifecycle: sign-up, sign-in, magic links, OAuth (Google, GitHub), session persistence, and token refresh. You configure it by adding the Supabase plugin in WeWeb and pasting your Project URL and anon key. No custom code is required.

How do I protect pages in WeWeb?

Open the page settings for any page that requires authentication and enable the Auth Guard option. Set it to "Redirect if not authenticated" and choose your Login page as the redirect target. WeWeb evaluates the guard before rendering — unauthenticated users are redirected before the page or any data fetches load. For role-based access, use the onPageLoad workflow to query the user's role and redirect if they lack permission.

Can WeWeb handle multi-role apps?

Yes. Store the user's role in Supabase's user_metadata or in a dedicated roles table. In WeWeb, bind conditional rendering to the currentUser.user_metadata.role value to show or hide UI elements by role. Pair this with Supabase Row Level Security policies that enforce role-based data access at the database level — UI hiding alone is not sufficient for a secure multi-role app.

WeWeb Authentication: Complete Setup Guide with Supabase Auth

Authentication is the single most-asked question in every WeWeb community, forum, and support channel. How do you protect pages? How do you handle roles? How do you implement Google login? This guide answers all of it in one place. By the end, you'll have a fully working auth system — email/password, magic link, OAuth, protected routes, and user roles — built on WeWeb and Supabase Auth.

WeWeb Auth Options Overview

WeWeb supports three authentication approaches, and choosing the right one upfront saves significant rework later.

The first and most common option is the native Supabase plugin. If you're using Supabase as your database — which covers the majority of WeWeb projects — this is the path you want. The WeWeb Supabase plugin handles sign-up, sign-in, OAuth, magic links, session management, and token refresh in a single integration. No separate auth service needed.

The second option is Auth0 via WeWeb's dedicated Auth0 plugin. This makes sense for enterprise projects where the organisation already has an Auth0 tenant, needs specific enterprise SSO (SAML, LDAP), or has compliance requirements that mandate a dedicated identity provider. Auth0 is more complex to configure and adds a per-user cost, but it's the right choice when corporate IT requirements mandate it.

The third option is a custom JWT flow using WeWeb's generic auth plugin. This is for teams with an existing backend (a custom Node.js API, a Laravel app, Xano) that already issues JWTs. WeWeb can accept a JWT from any source and use it for session management. If your backend is Xano, the Xano auth plugin handles this automatically.

For new projects starting from scratch, the Supabase plugin is the correct default. It's the most capable, the best-documented, and the most deeply integrated option WeWeb offers. Everything in this guide uses the Supabase plugin. Visit the WeWeb tool page for a broader overview of the platform.

Setting Up Supabase Auth for Your WeWeb Project

Before configuring WeWeb, make sure your Supabase project's auth settings are correct. In the Supabase dashboard, navigate to Authentication > URL Configuration. Set your Site URL to your WeWeb app's production domain (e.g. https://yourapp.com). In the Redirect URLs list, add both your production URL and your WeWeb editor preview URL — typically https://editor.weweb.io. These redirect URLs control where Supabase sends users after they click an email confirmation link or OAuth callback. Incorrect redirect URLs are the most common cause of "invalid redirect" errors in WeWeb auth.

For OAuth providers, each one requires its own setup. In Supabase Authentication > Providers, you'll see toggles for Google, GitHub, Discord, and others. Each enabled provider needs a Client ID and Client Secret, which you obtain by creating an OAuth app in that provider's developer console. For Google, go to console.cloud.google.com, create a project, enable the OAuth consent screen, and create OAuth 2.0 credentials. The Authorized Redirect URIs must include your Supabase project's callback URL: https://[your-project-ref].supabase.co/auth/v1/callback.

In WeWeb, add the Supabase plugin from the Plugins panel. Paste your Supabase Project URL and anon public key — both found in Supabase Settings > API. Once saved, WeWeb will show the auth section inside the Supabase plugin panel with configuration options for each auth provider you've enabled in Supabase.

Email/Password Auth in WeWeb

Create a Login page and a Sign Up page in WeWeb, or combine them in a single page with conditional rendering. For the sign-up form, add two TextField components (email, password) and a Submit button. In the button's click workflow, add the Supabase action "Sign Up." Map the email and password TextFields to the action's inputs. On success, navigate to your main authenticated page. On error, display the error message in a Text component bound to the workflow's error output.

For the sign-in form, the pattern is identical using the "Sign In with Email" Supabase action. After a successful sign-in, the Supabase plugin automatically stores the user's session in local storage — the session persists across page refreshes and browser restarts until the user signs out or the token expires and cannot be refreshed.

Session management in WeWeb is mostly automatic when using the Supabase plugin. The plugin exposes a currentUser variable (accessible throughout your app) that contains the user's ID, email, and metadata. It also handles token refresh automatically — Supabase JWTs expire after one hour, but the plugin silently refreshes them using the stored refresh token. You don't need to write any token refresh logic.

For sign-out, add a button with the Supabase "Sign Out" action, followed by a navigation action to redirect to your Login page. Test the complete cycle in a private browser window: sign up, confirm the email (check Supabase Authentication > Users to see the user was created), sign in, and verify the currentUser variable is populated. If you'd like this built correctly from day one, our team has implemented auth on 50+ production no-code apps.

Magic Link and OAuth in WeWeb

Magic link authentication eliminates passwords entirely — users enter their email and receive a sign-in link. In WeWeb, the Supabase "Send Magic Link" action handles the full flow. Create a simple form with an email TextField and a Send Link button. Wire the button to the "Send Magic Link" action with the email field as input. After clicking, the user receives an email with a link. When they click it, Supabase verifies the token and redirects back to your app — use the redirect URL you configured in Supabase to control the landing page.

For OAuth (Google, GitHub, etc.), the flow is initiated by a single WeWeb action: "Sign In with OAuth Provider." Select Google or GitHub from the provider dropdown. When triggered, WeWeb opens a popup or redirects to the provider's consent screen. After the user approves, Supabase handles the callback, creates or looks up the user in auth.users, and returns an active session. The currentUser variable will be populated with the OAuth user's data including their email, name, and provider-specific avatar URL.

A practical implementation detail for Google OAuth: in your Supabase project, enable the Google provider and paste your Google OAuth Client ID and Client Secret. In Google Console, under Authorized Redirect URIs for your OAuth credentials, add https://[your-project-ref].supabase.co/auth/v1/callback. Also add your WeWeb app's domain to the Authorized JavaScript Origins list. Missing either of these is the most common reason Google OAuth fails. GitHub OAuth follows an identical pattern through GitHub's Developer Settings > OAuth Apps.

Protected Pages and Route Guards in WeWeb

Once auth is working, you need to prevent unauthenticated users from accessing protected pages. WeWeb handles this at the page level through the Auth Guard setting.

For each page that requires authentication, open the page settings (click the page name in the Pages panel, then the gear icon) and enable Auth Guard. Set the guard type to "Redirect if not authenticated" and choose your Login page as the redirect target. WeWeb evaluates the guard before the page renders — if there's no active session, the redirect happens immediately, before any page content loads or any data fetches run.

For pages that should only be accessible when the user is NOT authenticated (like the Login page itself), set the guard to "Redirect if authenticated" and point it at your Dashboard. This prevents logged-in users from seeing the login screen when they navigate back to it.

For more complex logic — checking not just whether a user is logged in but whether they have a specific role or belong to a specific workspace — use the onPageLoad workflow instead of (or in addition to) the page-level auth guard. In the onPageLoad workflow, add a condition that checks a Supabase query result or a user metadata field, and navigate away if the condition is not met. This pattern is necessary for multi-tenant apps where you need to verify workspace membership before rendering the page.

User Roles and Permissions

Most production apps need more than a binary authenticated/unauthenticated check. You need roles: admin, member, viewer, or custom roles specific to your product. WeWeb and Supabase handle this through a combination of Supabase's user metadata and Row Level Security policies.

The simplest approach: store the user's role in the user_metadata field on Supabase's auth.users table. When creating a user, pass the role in the metadata object. For existing users, update metadata via the Supabase admin client. In WeWeb, the currentUser variable includes user_metadata — bind it to conditional rendering logic to show or hide UI elements based on role: `currentUser.user_metadata.role === 'admin'`.

For data-level permissions, implement Row Level Security policies in Supabase that use the user's role. Example: a policy that allows SELECT on the all_reports table only when auth.jwt()->'user_metadata'->'role' = 'admin'. This means even if a non-admin user calls the API directly, the database returns no rows. The RLS policy is your last line of defence — don't rely only on hiding UI elements in WeWeb.

For more complex role hierarchies, create a dedicated roles or memberships table in Supabase and join it in your RLS policies. This is the standard approach for multi-tenant SaaS apps where roles are per-workspace rather than global. The Supabase tool page covers RLS policy patterns in more depth.

Common Auth Mistakes to Avoid

Redirect loop on the login page is the most common auth bug. It happens when the Login page itself has an auth guard that redirects unauthenticated users to... the Login page. The fix: never put an "if not authenticated, redirect here" guard on the same page that is your redirect target. The Login page should have either no guard or a "redirect if authenticated" guard pointing to the Dashboard.

Token expiry not handled gracefully causes silent failures hours after login. Supabase JWTs expire after one hour. The WeWeb Supabase plugin handles refresh automatically, but only when the app is active in the browser. If a user leaves the tab open for several hours and comes back, the session may have expired. The fix: in your app's global onPageLoad or in any workflow that triggers an important action, check that currentUser is still populated and redirect to login if not.

Missing CORS configuration breaks auth in production even when it works in the editor. In Supabase, under Settings > API, make sure your production domain and WeWeb preview domain are both listed in the allowed origins. WeWeb's editor runs on a different domain than your published app, so you may test successfully in the editor and hit CORS errors after publishing.

Storing sensitive data in user_metadata is a security risk. user_metadata is included in the JWT and is visible to the client. Never store payment status, subscription tier, or any data that should not be user-readable in this field. Use a secure server-side table with RLS instead, and query it after login to fetch the user's authoritative data.