Error de Supabase: "Unsupported provider: provider is not enabled"

Añades un botón "Iniciar sesión con Google" a tu app y lo pulsas. En lugar del selector de cuentas de Google, tu navegador muestra esto:

{"code":400,"error_code":"validation_failed","msg":"Unsupported provider: provider is not enabled"}

La barra de direcciones muestra tu proyecto de Supabase, algo como https://abcdefghij.supabase.co/auth/v1/authorize?provider=google&redirect_to=…. Hiciste la app con Lovable, Bolt, v0, Cursor, Claude Code o Replit, el botón vino con el código, y nada en ese código parece estar mal.

"Unsupported provider: provider is not enabled" significa que Supabase Auth, la parte de Supabase que inicia la sesión de la gente, tiene Google desactivado en el proyecto con el que habla tu app. El arreglo es un interruptor y dos valores que te da Google. Después, Google revisa una lista propia, y de esa lista sale el siguiente error, redirect_uri_mismatch.

La trampa está en esa segunda lista. La dirección que parece correcta para ella es la de tu propia app, y Google nunca la usa, porque Google nunca envía a nadie a tu app.

¿Qué significa "Unsupported provider: provider is not enabled"?

Significa que Supabase se negó a empezar un inicio de sesión con Google, porque Google está desactivado en el proyecto que recibió la petición.

Iniciar sesión con Google es un viaje de ida y vuelta por dos recepciones. Tu app envía a la persona a la recepción de Supabase. Supabase la envía a la recepción de Google para demostrar quién es, Google la devuelve a Supabase, y Supabase la manda de vuelta a casa, a tu app, con la sesión iniciada. Cada recepción envía a la gente solo a donde sus propios ajustes lo permiten. Este mensaje es la recepción de Supabase diciendo que su ventanilla de Google está cerrada.

En el código fuente de Supabase Auth, una petición a /auth/v1/authorize busca primero el proveedor, y cualquier problema con él vuelve como un 400, con el código validation_failed y Unsupported provider: delante del motivo. provider is not enabled es lo primero que comprueba esa búsqueda.

Así que Google nunca vio la petición, y nada en la consola de Google lo va a explicar. Tu app tampoco ve el error: la biblioteca de JavaScript de Supabase envía todo el navegador a esa dirección, así que la página que falla es de Supabase, y la consola de tu app se queda vacía.

El mismo mensaje aparece con GitHub, Apple o cualquier otro proveedor desactivado, y el interruptor está en el mismo sitio. Las apps en el backend integrado de Lovable se configuran de otra manera: la documentación de autenticación de Lovable describe Google como "managed by Lovable with no setup, or your own Google Cloud OAuth credentials." Este artículo es para apps en tu propio proyecto de Supabase, sea cual sea la herramienta con la que se hicieron.

¿Es el proyecto de Supabase correcto?

Compruébalo antes de cambiar nada, porque la página de error nombra el proyecto que respondió.

La dirección de la página de error empieza por la referencia de tu proyecto, la serie de letras antes de .supabase.co. Abre tu panel de Supabase y mira su propia barra de direcciones: la misma referencia va después de /project/. Si las dos no coinciden, tu app habla con otro proyecto, por ejemplo uno que un builder creó por ti o una copia que hiciste para pruebas. Ese es el proyecto donde hay que activar Google.

Cómo arreglar "Unsupported provider: provider is not enabled"

Crea un cliente OAuth en Google y luego activa Google en Supabase con los dos valores que te da. La guía de inicio de sesión con Google de Supabase tiene los pasos; aquí están en el orden en que los piden las dos consolas. Las etiquetas son las de las dos interfaces en inglés.

En Supabase, copia primero la URL de callback. Ve a Authentication, luego a Sign In / Providers, y abre Google. El panel muestra una Callback URL con un botón para copiarla. Tiene esta forma: https://<project-ref>.supabase.co/auth/v1/callback.

En Google Cloud, crea el cliente. En la página Clients de Google Auth Platform, crea un ID de cliente OAuth de tipo Web application.

• En Authorized JavaScript origins, añade la dirección de tu app, por ejemplo https://yourapp.com.
• En Authorized redirect URIs, pega la URL de callback que copiaste en Supabase.
• Pulsa Create y copia en ese momento el Client ID y el Client Secret. La página de ayuda de Google sobre clientes OAuth avisa: "you will only be able to view and download the full client secret once, at the time of its creation."

De vuelta en Supabase, actívalo. Activa Enable Sign in with Google, pega el Client ID en Client IDs y el secreto en Client Secret (for OAuth), y guarda. El panel no guarda Google activado sin un Client ID, pero sí lo guarda con el campo del secreto vacío. La descripción de ese campo dice que el secreto es para "the OAuth flow on the web", y un botón en una app web es justo ese flujo.

Luego pulsa tu botón otra vez. Si el mensaje sigue empezando por "Unsupported provider", su final te dice lo que falta:

Por qué Google responde después redirect_uri_mismatch

Porque tu URL de callback no está en la lista del cliente, escrita exactamente como la envía Supabase.

Esta es la segunda recepción. Cuando Supabase empieza el inicio de sesión, pasa a la persona a Google con una nota que dice adónde devolverla: la URL de callback de tu proyecto. Google compara esa nota con las Authorized redirect URIs del cliente que creaste. Su documentación de OAuth describe el fallo en una línea: "The redirect_uri passed in the authorization request does not match an authorized redirect URI for the OAuth client ID."

La coincidencia es exacta. La misma página dice: "the http or https scheme, case, and trailing slash ('/') must all match." Así que una entrada que termina en /auth/v1/callback/, con una barra al final, no coincide con la dirección que envía Supabase.

La dirección de tu propia app no hace nada en esta lista. Google devuelve a la gente a Supabase, así que la única dirección que comprueba es el callback de Supabase. La dirección de tu app va en la lista de la otra recepción, Redirect URLs en Supabase, que decide adónde envía Supabase a la gente al final del todo. Cuando esa lista está mal, la gente vuelve con la sesión iniciada en localhost:3000, y eso tiene su propio artículo.

Después de guardar, dale a Google un poco de tiempo. Su página de ayuda sobre clientes OAuth dice: "It may take 5 minutes to a few hours for changes made to these settings to take effect."

Dónde va el Client Secret

En el panel de Supabase, y en ningún otro sitio. El código de tu app nunca lo necesita.

El Client ID es público: viaja en la dirección de la página de inicio de sesión de Google, donde cualquiera puede leerlo. El Client Secret es lo que demuestra a Google que una petición viene de tu lado, y en este montaje solo lo tiene Supabase. Cuando tu app llama a signInWithOAuth, la biblioteca envía el navegador a Supabase, y es Supabase Auth quien habla con Google usando el secreto.

Así que si tu builder puso el secreto en el código de tu app, o en una variable cuyo nombre empieza por VITE_ o NEXT_PUBLIC_, está en el navegador de cada visitante. Esas variables son públicas por diseño. La página de ayuda de Google lo dice sin rodeos: "Never add client secrets directly in your code or check them into version control systems such as Git or Subversion." Cámbialo en la página del cliente en la consola de Google: pulsa Add Secret, pega el secreto nuevo en Supabase, luego Disable en el antiguo y bórralo. Quita también el valor antiguo de tu código.

Para revisar lo que tu app en vivo entrega a los visitantes no hace falta abrir el builder. Nuestro escaneo gratuito lee tu app en vivo como lo hace el navegador de un visitante e informa de las claves secretas que reconoce, además de las tablas que responden a cualquiera y las cabeceras que faltan. Tarda unos 20 segundos y no necesita cuenta: escanea tu app.

Cuidar la app en la que ahora inicia sesión la gente

En cuanto la gente inicia sesión con Google, sus cuentas viven en tu proyecto de Supabase, y la app en la que entran cambia con cada despliegue.

Reeve Monitor sigue comprobando tu app en vivo:

• si está disponible, cada 60 segundos
• las nueve comprobaciones cada hora, en hasta tres apps, incluidas las claves secretas en el código que tu app envía a los visitantes
• un mensaje cuando un resultado cambia, para que una clave que sale con un despliegue posterior te llegue sin que tengas que ir a mirar
• un informe mensual, en lenguaje claro, de lo que vio

Reeve Care guarda una copia de tu base de datos de Supabase, con las cuentas incluidas:

• una copia cifrada según una programación, en el almacenamiento propio de Reeve en la UE, fuera de tu cuenta de Supabase
• el esquema auth, donde Supabase guarda a cada usuario y la identidad de Google con la que inició sesión, para que vuelvan con todo lo demás
• cada copia verificada antes de contar, contando las filas de cada tabla
• también tus archivos subidos, en cuanto conectes una credencial de Storage
• una restauración en un clic, con una copia de seguridad del estado actual tomada antes
• todo lo que hace Monitor

Qué hacer ahora

Si la gente pasa por Google y luego llega a la página equivocada, el artículo sobre las redirecciones sigue desde ahí. La checklist de seguridad de 10 minutos cubre lo que queda por mirar antes del lanzamiento.