WeWeb User Authentication: Supabase Auth, Auth0, Xano, and Social Login

WeWeb offers four auth options, each with different trade-offs. Supabase Auth: the recommended default for most WeWeb projects. Natively integrates with the Supabase data source plugin — the auth token is automatically forwarded to all Supabase database operations. Supports email/password, magic links, phone OTP, and 20+ social OAuth providers. Free tier allows 50,000 monthly active users. Auth0: recommended for enterprise projects requiring advanced identity features — MFA, custom rules, enterprise SSO (SAML), extensive audit logs, or compliance requirements (SOC 2, HIPAA). Auth0 free tier supports 7,000 active users. The Auth0 WeWeb plugin auto-creates Machine-to-Machine and Single Page Application apps in Auth0. Xano Auth: use only if your backend is already Xano. The token is automatically forwarded to all Xano API calls. Requires 3 standard auth endpoints in Xano (signup, login, me). WeWeb Auth: explicitly NOT recommended for production — WeWeb's documentation states this is proof-of-concept only, not suitable for large user bases. Token-based Auth: for custom auth APIs not covered by the above options.

In the WeWeb editor, click Plugins in the left navbar → Authentication section → Supabase Auth. If you have already added the Supabase backend plugin, the auth plugin auto-detects your Supabase credentials and auto-connects. Click 'Connect' → your Supabase project is linked. In the Supabase Auth plugin settings, configure: Default page for unauthenticated users (the page non-logged-in users are redirected to — typically your login page). This page MUST be public. Set Redirect page after login (the page users land on after successful login — typically your app's dashboard or home page). Click 'Generate' to automatically create the `roles` table and `users_roles` join table in your Supabase database — these are needed for role-based access control later. Review the SMTP configuration notice: for production email delivery (signup confirmation, password reset), configure your own SMTP provider in the Supabase Dashboard → Authentication → Settings → SMTP Settings. Without custom SMTP, Supabase's shared email server has low rate limits and poor deliverability.

Create or navigate to your login page. This page must be set to Public in Page settings → Access control. Add a Form Container → inside it add: an Input element (type: email, name: 'email', required validation), an Input element (type: password, name: 'password', required validation), and a Button ('Sign in'). Add a workflow to the Form Container's On submit event → Action: Supabase Auth → Log in → bind Email to formContainer['formData'].email and Password to formContainer['formData'].password. Add a success branch: if login succeeds, the plugin automatically redirects to the page you configured. For explicit navigation: add Navigate action → your dashboard page. Add an error branch: Change variable value → 'loginError' String → 'Invalid email or password' → bind a Text element below the button to display this error message. The error text element's display should be bound to `loginError.length > 0`.

Create a signup page (also public). The signup form needs: email input, password input, optional confirm password input. Add a Form Container → On submit workflow → Supabase Auth → Sign up → bind Email and Password fields. If you are requiring password confirmation, add a custom validation formula on the confirm_password input: `formContainer['formData'].password === formContainer['formData'].confirm_password`. In Supabase, email confirmation is enabled by default — users receive an email and must click a confirmation link before they can log in. In this case, after signup, do not auto-redirect to the dashboard. Instead, show a message: 'Please check your email and click the confirmation link to activate your account.' If you want to disable email confirmation for faster onboarding: go to Supabase Dashboard → Authentication → Providers → Email → disable 'Confirm email'. Only do this for internal tools or during development — production apps should keep confirmation enabled to verify email addresses.

Social login requires two steps: configuring the OAuth provider in Supabase (outside WeWeb), then calling it from WeWeb. OUTSIDE WEWEB — in Supabase Dashboard: go to Authentication → Providers → Google → toggle Enable. Create a Google OAuth app: go to console.cloud.google.com → APIs & Services → Credentials → Create OAuth 2.0 Client ID (Web application type). Authorized redirect URI: paste your Supabase callback URL shown in the Supabase Google provider settings (format: https://[project-ref].supabase.co/auth/v1/callback). Copy the Client ID and Client Secret from Google → paste into Supabase → Save. IN WEWEB: on your login page, add a Button ('Continue with Google'). Add a workflow: On click → Supabase Auth → Login with provider → select 'google' → Redirect to: your post-login page URL. The redirect page after OAuth login MUST be public. When the OAuth flow completes, Supabase redirects back to WeWeb with a token in the URL. WeWeb's Supabase Auth plugin reads this token automatically and logs the user in. For multiple social providers, repeat this process (GitHub, Apple, LinkedIn, etc.) — each requires its own OAuth app setup outside WeWeb.

Password reset requires a dedicated reset page and a two-step email flow. Step 1 — Request reset: Add a 'Forgot password?' link on the login page. It navigates to a Reset Password Request page (public). This page has a single email input and a submit button. On submit workflow: Supabase Auth → Reset password → bind Email to the input value. This triggers Supabase to send a password reset email. After the action, show a message: 'Check your email for a password reset link.' OUTSIDE WEWEB — in Supabase Dashboard: Authentication → Email Templates → Reset Password. The default template links to your Supabase auth URL. For WeWeb, change the redirect URL to your WeWeb reset confirmation page: `https://yourdomain.com/reset-confirm?token={{ .Token }}`. Step 2 — Set new password: Create a Reset Confirm page (public, URL: /reset-confirm). This page has a new password input and confirm password input. On page load workflow: extract the token from the URL query variable. On submit: Supabase Auth → Update user → bind new password. After success, navigate to the login page with a success message.

After successful login, WeWeb's Supabase Auth plugin stores the user object at `wwContext.user`. Access it in any binding formula throughout your app. Common bindings: Display user's name: `wwContext.user.user_metadata.full_name || wwContext.user.email`. Show/hide content based on login state: bind Conditional Rendering to `wwContext.user !== null`. The user's ID: `wwContext.user.id`. The user's email: `wwContext.user.email`. User roles (after using the Generate button): `wwContext.user.roles` (array of role objects). To use the current user's ID in a Supabase collection filter (e.g., fetch only this user's records): in the collection's Filters section, add: `user_id equals [plug icon] → wwContext.user?.id`. Enable 'Ignore if empty' so the collection doesn't run when the user is not logged in. Logout: add a workflow to any button: Supabase Auth → Log out → then Navigate to the login page. After logout, `wwContext.user` becomes null and any collection with user-based filters automatically refetches empty.

1// Injection point: binding formula examples for use throughout WeWeb
2
3// Check if user is logged in:
4wwContext.user !== null
5
6// Display user's name (with fallback to email):
7wwContext.user?.user_metadata?.full_name || wwContext.user?.email || 'Guest'
8
9// Check if user has a specific role:
10wwContext.user?.roles?.some(r => r.name === 'admin')
11
12// User's avatar URL (if set in user_metadata):
13wwContext.user?.user_metadata?.avatar_url
14
15// Filter a collection to the current user's records:
16// Collection filter: user_id equals wwContext.user?.id
17
18// Check if email is confirmed:
19wwContext.user?.email_confirmed_at !== null