This error occurs when attempting to sign in with an OAuth provider that has not been enabled in your Supabase project settings. The fix requires enabling the provider in the Supabase Dashboard under Authentication settings.
The "oauth_provider_not_supported" error occurs when your application attempts to authenticate users with an OAuth provider (like Google, GitHub, Discord, etc.) that hasn't been explicitly enabled in your Supabase project configuration. Supabase Auth requires each OAuth provider to be individually configured and enabled before it can be used for authentication. This is a security measure to ensure that only intentionally configured authentication methods are available in your application. When a sign-in request is made for a disabled provider, Supabase immediately rejects it with this error. This error is most commonly encountered during initial setup or when adding a new OAuth provider to an existing application, but can also occur if a provider was accidentally disabled or if there are configuration mismatches between local and production environments.
Log in to your Supabase Dashboard at https://app.supabase.com and select your project. In the left sidebar, click on Authentication, then navigate to the Providers section.
You should see a list of available OAuth providers (Google, GitHub, Discord, Facebook, Twitter, etc.). Check whether the provider you're trying to use is currently enabled.
Locate the OAuth provider you want to use in the providers list and toggle the switch to enable it.
For example, to enable Google authentication:
1. Find "Google" in the providers list
2. Click the toggle to enable it
3. The provider settings panel will expand
The provider is now enabled, but you still need to configure credentials.
Each OAuth provider requires a Client ID and Client Secret from the provider's developer console. For example, for Google:
1. Go to [Google Cloud Console](https://console.cloud.google.com/)
2. Create a new project or select an existing one
3. Navigate to APIs & Services > Credentials
4. Create an OAuth 2.0 Client ID
5. Set the authorized redirect URI to:
https://your-project-ref.supabase.co/auth/v1/callback6. Copy the Client ID and Client Secret
Back in the Supabase Dashboard, paste these credentials into the respective fields and click Save.
Repeat this process for each OAuth provider you want to enable, following Supabase's provider-specific documentation.
In the Supabase Dashboard, navigate to Authentication > URL Configuration.
Add your application's redirect URLs to the Redirect URLs allowlist:
http://localhost:3000/**
https://yourdomain.com/**For local development, ensure http://localhost:3000 (or your dev port) is included. For production, add your production domain.
These URLs tell Supabase where to redirect users after successful authentication.
Verify your sign-in code is using the correct provider name. For example, with the Supabase JavaScript client:
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
)
// Sign in with OAuth
const { data, error } = await supabase.auth.signInWithOAuth({
provider: 'google', // Must match enabled provider name
options: {
redirectTo: 'http://localhost:3000/auth/callback'
}
})
if (error) {
console.error('OAuth error:', error.message)
}Common provider names: google, github, discord, facebook, twitter, azure, linkedin, etc.
Clear your browser cache and test the OAuth sign-in flow:
1. Click your social login button
2. You should be redirected to the provider's authorization page
3. After authorizing, you should be redirected back to your application
4. Check the browser console and network tab for any errors
If the error persists, verify:
- Environment variables are pointing to the correct Supabase project
- The provider name in code exactly matches the enabled provider
- Redirect URLs match between your app, Supabase settings, and OAuth provider console
Self-hosted Supabase: If you're running a self-hosted Supabase instance, OAuth providers are configured in the supabase/config.toml file under the [auth.external] section. You'll need to enable providers and set credentials there instead of the dashboard.
Multiple environments: When working with multiple environments (development, staging, production), each Supabase project needs its own OAuth provider configuration. A common mistake is configuring OAuth in one environment but forgetting to replicate the setup in others.
Rate limiting: Some OAuth providers (like Google) have rate limits on authentication requests during development. If you're testing frequently, you might hit these limits temporarily.
PKCE flow: Supabase uses the Authorization Code Flow with PKCE (Proof Key for Code Exchange) for OAuth, which is more secure than implicit flow. This requires proper redirect URL configuration and may not work with older OAuth provider configurations.
Provider-specific quirks: Some providers have additional requirements. For example, LinkedIn requires your application to be verified before OAuth works in production, and Apple requires specific domain verification steps.
email_conflict_identity_not_deletable: Cannot delete identity because of email conflict
How to fix "Cannot delete identity because of email conflict" in Supabase
mfa_challenge_expired: MFA challenge has expired
How to fix "mfa_challenge_expired: MFA challenge has expired" in Supabase
conflict: Database conflict, usually related to concurrent requests
How to fix "database conflict usually related to concurrent requests" in Supabase
phone_exists: Phone number already exists
How to fix "phone_exists" in Supabase
StorageApiError: resource_already_exists
StorageApiError: Resource already exists