Supabase Auth coverage
Supacharger builds its shared authentication journey on Supabase Auth. This page distinguishes between features available from Supabase and features wired end-to-end in the canonical Supacharger application. A green tick means supported; a dash means the shared Supacharger UI, server actions, callback handling, and configuration contract do not yet provide that complete journey.
Phone authentication is outside the scope of this coverage.
Authentication methods
| Authentication method | Supabase Auth | Supacharger | Supacharger coverage |
|---|---|---|---|
| Email and password | Configurable sign-in and sign-up, password-strength validation, email confirmation, and protected password changes. | ||
| Passwordless email sign-in: OTP | Sends an email code to an existing user, renders a configurable 6–10 digit input, and verifies with type: 'email'. | ||
| Passwordless email sign-in: magic link | Sends a sign-in link to an existing user and completes the PKCE flow through /auth/confirm. | ||
| Passwordless email sign-up | — | A guarded server action and configuration value exist, but the shared signup form does not currently invoke the signup action end-to-end. | |
| Password sign-up confirmation: OTP | The confirmation email contains a code and the form verifies it with type: 'signup'. | ||
| Password sign-up confirmation: link | The confirmation email links to /auth/confirm, which verifies the token hash and preserves a safe return path. | ||
| Password sign-up confirmation: OTP and link | One email offers both credentials. They represent the same one-time verification, so using either invalidates the other. | ||
| Password reset by email link | Exchanges the recovery PKCE code at /auth/callback, verifies recovery AMR, then opens /account/reset-password/new for the protected password update. | ||
| Built-in social OAuth/OIDC | The 21 supported Supacharger provider identifiers use signInWithOAuth() and return through /auth/callback. | ||
| Custom OAuth/OIDC providers | — | Supabase accepts custom: provider identifiers, but Supacharger's typed provider map and buttons currently accept only the built-in identifiers listed below. | |
| Enterprise SSO with SAML 2.0 | — | Supabase provides SAML SSO; Supacharger has no SSO discovery, organisation-domain, or SAML callback journey. | |
| Passkeys (WebAuthn) | — | Supabase passkeys are experimental. Supacharger has no client opt-in, enrollment, sign-in, or credential-management UI. | |
| Web3 wallet sign-in | — | Supabase supports Ethereum and Solana wallets; Supacharger has no wallet discovery or signing journey. | |
| Anonymous sign-in | — | Supacharger can be configured to accept an existing anonymous session, but it does not create anonymous users or provide an upgrade/linking journey. | |
| TOTP multi-factor authentication | Account Security provides factor enrolment, verification, listing, and removal; the sign-in journey can require AAL2 for enrolled accounts. | ||
| OAuth 2.1/OIDC server | — | Supabase can make a project an identity provider for other applications. Supacharger does not ship the required authorization and consent experience. |
The email code and link modes share Supabase's Magic Link or OTP template. Passwordless sign-in selects one mode at a time. Password sign-up confirmation can select OTP, link, or both. See Authentication and route protection for configuration, callback behaviour, and the consumed-code/link edge case.
The unsupported rows are not enabled by adding an icon or changing a Supabase Dashboard toggle. Each needs a complete application journey and a corresponding addition to Supacharger's configuration contract, server boundary, tests, and documentation. Refer to Supabase's current guides for custom OAuth/OIDC providers, SAML SSO, passkeys, Web3, anonymous sign-in, MFA, and the OAuth 2.1 server before extending coverage.
Supported social OAuth/OIDC providers
Supabase documents 19 built-in social provider families. Supacharger exposes 21 configuration identifiers because Slack and Twitter/X each have a preferred current integration and a legacy compatibility integration.
Enable a button with AUTH_PROVDERS_ENABLED, then enable and configure the same provider in every relevant Supabase environment. A button alone does not configure the hosted provider, its secret, or its redirect allow-list.
| Icon | Provider | Configuration identifier | Supacharger |
|---|---|---|---|
 | Apple | apple | |
 | Microsoft Azure | azure | |
 | Bitbucket | bitbucket | |
 | Discord | discord | |
 | facebook | ||
 | Figma | figma | |
 | GitHub | github | |
 | GitLab | gitlab | |
 | google | ||
 | Kakao | kakao | |
 | Keycloak | keycloak | |
 | LinkedIn (OIDC) | linkedin_oidc | |
 | Notion | notion | |
 | Twitch | twitch | |
 | X / Twitter (OAuth 2.0) | x | |
 | Twitter (OAuth 1.0a, legacy) | twitter | |
 | Slack (OIDC) | slack_oidc | |
| Slack (legacy OAuth) | slack | |
 | Spotify | spotify | |
 | WorkOS | workos | |
 | Zoom | zoom |
Prefer LinkedIn OIDC, Slack OIDC, and X/Twitter OAuth 2.0 for new integrations. The Slack legacy and Twitter OAuth 1.0a identifiers remain available only for compatibility.
Every supported provider uses the OAuth PKCE callback at /auth/callback. Add the exact URL to the Supabase redirect allow-list. Browser code uses the project URL and a publishable key; never expose a secret or service-role key through a NEXT_PUBLIC_ variable.
Provider artwork lives in the CLI-managed src/supacharger/assets/svgr/auth-providers/ directory and is rendered by the shared provider-button component. Project UI can enable any subset of the supported provider map.