SAML SSO authentication
SAML-based Single Sign-On for authentication. This feature is generally available and fully available on self-hosted deployments.
auth
381 notes in this subject, read out of this brain and free to use. This is page 1 of 7.
CAPTCHA protection for authentication forms
Add CAPTCHA to sign-in, sign-up, and password reset forms. This feature is generally available and fully available on self-hosted deployments.
Third-party authentication
Support for third-party authentication providers. This feature is generally available and fully available on self-hosted deployments.
Server-side auth helpers
Helpers for implementing user authentication in popular server-side languages and frameworks like Next.js, SvelteKit and Remix. This feature is in beta status and fully available on self-hosted deployments.
Email login authentication
Build email logins for your application or website. This feature is generally available and fully available on self-hosted deployments.
Social login providers
Provide social logins including Apple, GitHub, Slack, and other providers. This feature is generally available and fully available on self-hosted deployments.
Passwordless login with magic links
Build passwordless logins via magic links for your application or website. This feature is generally available and fully available on self-hosted deployments.
Auth hooks for custom authentication logic
Hooks allow you to run custom logic during authentication flows. This feature is in beta status and fully available on self-hosted deployments.
Phone login authentication
Provide phone logins using a third-party SMS provider. This feature is generally available and fully available on self-hosted deployments.
Initialize Supabase client for Expo with localStorage persistence
Create lib/supabase.ts to initialize the Supabase client. Import 'react-native-url-polyfill/auto' first, then 'expo-sqlite/localStorage/install'. Call createClient with the Supabase URL and publishable key. Configure auth options with storage: localStorage, autoRefreshToken: true, persistSession: true, and detectSessionInUrl: false to persist authentication sessions using Expo's localStorage polyfill.
Enable anonymous sign-ins for Hono auth
Enable anonymous sign-ins in the Auth settings of your Supabase project dashboard before using authentication in the Hono app.
Deep linking setup required for iOS auth features
To implement authentication features like magic links or OAuth in iOS, you must set up deep links to redirect users back to your app. This requires configuring custom URL schemes for the iOS app.
Flutter deep links setup for authentication
Many sign-in methods in Flutter require deep links to redirect users back to the app after authentication. Deep links must be set up for all platforms including web, and detailed instructions are available in the Flutter Mobile Guide.
Next.js environment variables for Supabase
Rename .env.example to .env.local and populate with NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY. These values can be obtained from the project Connect panel in the Supabase dashboard.
Next.js with Supabase uses Cookie-based Auth
The standard Next.js Supabase template is pre-configured with Cookie-based Auth for server-side authentication.
Magic Link authentication in Angular
Use Magic Links for passwordless email sign-in. This allows users to sign in with their email without using passwords. Email templates can be customized from the Authentication > Email section in the Supabase Dashboard.
LargeSecureStore implementation for Supabase auth
Create a LargeSecureStore class that implements getItem(), setItem(), and removeItem() methods. The class uses aes-js CTR mode cipher with a 256-bit encryption key stored in SecureStore. Values are encrypted with _encrypt() using crypto.getRandomValues() for the key, which is stored in SecureStore as hex, and the encrypted bytes are stored in AsyncStorage as hex. The _decrypt() method retrieves the key from SecureStore and decrypts values from AsyncStorage. Pass this class to the supabase createClient() as the auth storage option.
Install dependencies for secure session encryption
To implement encrypted sessions in Expo, install: npm install @supabase/supabase-js, npm install @react-native-async-storage/async-storage, npm install aes-js react-native-get-random-values, npm install --save-dev @types/aes-js, and npx expo install expo-secure-store.
Encrypt session data in Expo using SecureStore and AES
To encrypt user session information in Expo, use aes-js with a 256-bit encryption key generated via react-native-get-random-values. Store the encryption key in Expo's SecureStore and the encrypted session value in AsyncStorage. This is necessary because Expo's SecureStore has a 2048-byte size limit.
Supabase API keys are safe to expose in Expo apps
Supabase API URL and publishable key can be safely exposed in Expo client apps because Supabase has Row Level Security enabled on the database by default. The keys do not grant privileged access without proper authentication and authorization policies.
Email verification required by default in Supabase Auth
By default, Supabase Auth requires email verification before a session is created for users. To support email verification in React Native apps, implement deep link handling. For testing purposes, email confirmation can be disabled in the project's email auth provider settings in the dashboard.
Supabase client configuration for React Native with auth storage
When creating a Supabase client in React Native, configure the auth object with: storage (the storage implementation), autoRefreshToken: true, persistSession: true, and detectSessionInUrl: false. Example: createClient(supabaseUrl, supabasePublishableKey, { auth: { storage: new LargeSecureStore(), autoRefreshToken: true, persistSession: true, detectSessionInUrl: false } }).
Supabase publishable key is safe to expose
The publishable key can be safely exposed in the browser because it is restricted and Row Level Security is enabled on the database tables, such as the profiles table.
Deep link setup for Flutter magic link authentication
To enable magic link sign-in with deep links in Flutter, use the scheme `io.supabase.flutterquickstart` and host `login-callback`. Add `io.supabase.flutterquickstart://login-callback/` as a redirect URL in the Supabase Dashboard under Auth URL Configuration. For iOS, add CFBundleURLTypes to ios/Runner/Info.plist. For Android, add an intent-filter to android/app/src/main/AndroidManifest.xml with the scheme and host values. For web, use `usePathUrlStrategy()` from `flutter_web_plugins/url_strategy` in the main function instead of the default URL strategy.
Flutter conditional navigation based on auth state
Show different pages based on authentication state by checking `supabase.auth.currentSession == null`. Set the home property of MaterialApp to LoginPage if there is no session, otherwise set it to AccountPage. This allows the app to resume on the appropriate page when opened.
Flutter magic link sign-in with OTP
Implement magic link authentication using `await supabase.auth.signInWithOtp(email: _emailController.text.trim(), emailRedirectTo: kIsWeb ? null : 'io.supabase.flutterquickstart://login-callback/')`. The emailRedirectTo parameter should be omitted for web and set to the deep link URL for mobile platforms. Catch `AuthException` errors and display messages to the user.
Flutter sign out implementation
Sign out a user with `await supabase.auth.signOut()`. Catch `AuthException` for sign-out errors and navigate the user back to the login page after sign-out completes using Navigator.
Flutter auth state listener setup
Use `supabase.auth.onAuthStateChange.listen((data) { final session = data.session; ... })` to listen for authentication state changes. This fires when a user completes a magic link sign-in flow and returns to the app. Store the subscription in a late final variable and cancel it in dispose().
Supabase credentials are safe to expose in browser with Row Level Security
Supabase API credentials can be exposed in the browser because Supabase enables Row Level Security on Databases by default, protecting data access at the database level.
Magic Links authentication in Ionic Vue
Users can sign in with their email using Magic Links without passwords. This is implemented in a Login component that handles both logins and sign ups.
Magic Link authentication in React
Use Magic Links for passwordless authentication in a React login component. Magic Links allow users to sign in with their email only, without entering a password.
Customize authentication emails
Authentication emails sent to users can be customized from the Authentication > Email section in the Supabase Dashboard. You can customize the email's looks, content, and query parameters.
Magic link authentication with supabase.auth.signInWithOtp
To sign in users via magic link, call supabase.auth.signInWithOtp({ email: email.value }). This sends a login link to the user's email address.
Sign out with supabase.auth.signOut
Call supabase.auth.signOut() to sign out the current user. This is an async operation that returns an error object if it fails.
withSupabase middleware for h3/Nuxt server routes
Use the withSupabase middleware from @supabase/server/adapters/h3 in Nuxt server routes. Pass auth: 'user' to require authentication or auth: 'none' for unauthenticated routes. The middleware attaches supabase client and userClaims to event.context.supabaseContext.
Server route example with Supabase auth in Nuxt
Create a server route at server/api/profile.get.ts using withSupabase middleware with auth: 'user'. Access the authenticated supabase client and userClaims from event.context.supabaseContext to query user-specific data with RLS automatically applied.
@supabase/server for server-side authentication in Nuxt
Install @supabase/server (npm install @supabase/server) to handle authentication in Nuxt server routes. It validates JWTs locally using your project's asymmetric signing keys, attaches an RLS-scoped Supabase client and user claims to the request, and rejects unauthenticated requests with a 401.
App-wide server authentication in Nuxt
Register withSupabase({ auth: 'user' }) as a Nuxt server middleware at server/middleware/supabase.ts to apply authentication validation to all server routes app-wide, rather than per-route.
RedwoodJS Supabase Row Level Security requirement
Row Level Security must be enabled on the Supabase database for the public publishable key to be safely exposed in the browser. This allows the client-side application to authenticate requests and enforce database policies.
Magic Link authentication in Refine authProvider
To implement Magic Link authentication in Refine's authProvider.login method, use supabaseClient.auth.signInWithOtp({ email }). The method sends an OTP link to the user's email for passwordless sign-in. Handle the response by checking for errors and return { success: true } on successful OTP send.
Magic link authentication in SolidJS
The SolidJS tutorial demonstrates setting up a login component that uses Magic Links for email-based sign in without passwords.
User management app uses Magic Links for authentication
The Svelte user management tutorial implements Magic Links authentication, allowing users to sign in with their email without passwords.
Email template configuration for auth confirmation
To support server-side authentication flow in SvelteKit, modify email templates in the Auth dashboard: Go to Auth > Emails, select the "Confirm signup" template, and change `{{ .ConfirmationURL }}` to `{{ .SiteURL }}/auth/confirm?token_hash={{ .TokenHash }}&type=email`. Repeat this for the "Magic link" template.
SvelteKit auth confirmation endpoint pattern
Create a server endpoint at `src/routes/auth/confirm/+server.ts` to handle the authentication confirmation flow. This endpoint should retrieve the `token_hash` query parameter sent from the Supabase Auth server, exchange it for a session using the Supabase client, store the session in cookies, and redirect the user to the account page or error page.
Swift: Configure custom redirect URL for deep linking
To handle magic link redirects in a native Swift app, you must add a custom redirect URL to Supabase and configure a custom URL scheme in your SwiftUI application. See the native mobile deep linking guide for implementation details.
Swift: Get current authenticated user
Access the current user via `supabase.auth.session.user`. This requires an authenticated session and throws an error if not authenticated.
Swift: Handle deep link authentication callback
Use SwiftUI's `.onOpenURL` modifier to handle deep link URLs. Call `supabase.auth.session(from: url)` with the received URL to complete the authentication flow.
Swift: Sign out user
Call `supabase.auth.signOut()` to sign out the current user. Example: `try? await supabase.auth.signOut()`
Swift: Sign in with OTP magic link
Call `supabase.auth.signInWithOTP(email:redirectTo:)` to send a magic link to the user's email. The redirectTo parameter should specify a deep link URL scheme for the app to handle the authentication callback. Example: `try await supabase.auth.signInWithOTP(email: email, redirectTo: URL(string: "io.supabase.user-management://login-callback"))`
Swift: Listen to authentication state changes
Use `supabase.auth.authStateChanges` as an async sequence to listen for authentication state changes. The state contains an event property and a session property. Check for events like .initialSession, .signedIn, and .signedOut. Example: `for await state in supabase.auth.authStateChanges { if [.initialSession, .signedIn, .signedOut].contains(state.event) { isAuthenticated = state.session != nil } }`
Swift: Row Level Security enables publishable key exposure
It is safe to expose the Supabase API URL and publishable key in a client application because Row Level Security policies on the database ensure users can only access and modify their own data.
OAuth scopes restrict access to Supabase Management API
Scopes restrict access to the specific Supabase Management API endpoints for OAuth tokens. All scopes can be specified as read and/or write. Scopes are set when you create an OAuth app in the Supabase Dashboard and can be updated at any time, but existing OAuth app users will need to re-authorize via the OAuth flow to apply new scopes.
Complete list of OAuth scopes and their capabilities
Available OAuth scopes are: Auth (Read: retrieve project auth config and SAML SSO providers; Write: update auth config, create/update/delete SAML SSO providers), Database (Read: retrieve database config, pooler config, SQL snippets, read-only status, SSL enforcement, schema types; Write: create SQL query, enable webhooks, update database/pooler config, update SSL enforcement, disable read-only mode for 15 mins, create PITR backup), Domains (Read: retrieve custom domains and vanity subdomain config; Write: activate/initialize/reverify/delete custom domain, activate/delete/check availability of vanity subdomain), Edge Functions (Read: retrieve edge function info; Write: create/update/delete edge function), Environment (Read: retrieve branches; Write: create/update/delete branch), Organizations (Read: retrieve metadata and members; Write: N/A), Projects (Read: retrieve metadata, check upgrade eligibility, retrieve network restrictions and bans; Write: create project, upgrade database, remove network bans, update network restrictions), Rest (Read: retrieve PostgREST config; Write: update PostgREST config), Secrets (Read: retrieve API keys, secrets, pgsodium config; Write: create/update secrets, update pgsodium config), Storage (Read: retrieve storage buckets).
Partner integration Method 2 JWT validation steps
When receiving a JWT in Method 2, perform these validation steps in order: (1) Read the kid field from the JWT header and look up the matching public key. (2) Verify the JWT signature with that public key. (3) Verify that alg is ES256. (4) Verify that iss is 'supabase'. (5) Verify that aud matches the value agreed with Supabase. (6) Verify that the current time is between iat and exp. If any check fails, return 401 Unauthorized.
Partner integration Method 2 JWT protected header fields
The JWT protected header (JOSE header) for Method 2 contains two required fields: alg (always ES256, the only currently supported signing algorithm) and kid (the key ID identifying the key pair, used to pick the correct public key when verifying the signature).
Partner integration Method 2 JWT payload claims
The JWT payload contains the following claims: iss (required, always 'supabase'), aud (required, a unique string identifying the audience of this JWT, usually a URL), iat (required, issued-at timestamp in seconds since epoch), exp (required, expiry timestamp at most 5 minutes after iat), organization_slug (optional, the Supabase organization the user is connecting from, used to pre-select the org during OAuth consent screen), and project_id (optional, the Supabase project ref the user wants to connect, used to pre-select a Supabase project in your UI).
Partner integration Method 2 signed redirect public key exchange
For Method 2, Supabase generates two key-pairs (one for staging, one for production) and shares the public keys with the partner. The keys are PEM-encoded EC P-256. Both keys and their key IDs should be saved. The kid (key ID) field in the JWT header is used to look up the correct public key. Storing keys by ID enables zero-downtime key rotation when Supabase rotates keys and starts signing JWTs with a new key ID.
Mailpit captures emails from local Supabase Auth
The Supabase CLI uses Mailpit to capture emails sent from your local machine. This is useful for testing emails sent from Supabase Auth. Mailpit is available at localhost:54324 by default when you run `supabase start`.
Access Mailpit UI for testing Auth emails
When running `supabase start`, open localhost:54324 in your browser to view the emails captured by Mailpit during local testing.
Default Supabase email only for development
The default email provided by Supabase is only for development purposes and is heavily restricted to prevent spam. Before going into production, configure your own email provider by enabling SMTP credentials in your project settings under the Auth section.