Supabase Auth es el sistema de inicio de sesión integrado en Supabase: guarda a los usuarios en la base de datos Postgres de su proyecto, los autentica con contraseña, enlace mágico, código de un solo uso o un proveedor como Google, y emite la sesión que leen las reglas de su base de datos. Para añadir inicio de sesión a una aplicación web, usted pide a su creador de apps con IA los métodos de acceso y los roles, y después revisa tres ajustes en el panel de Supabase: la Site URL, las URL de redirección y el remitente de los correos.
Esta guía explica qué hace cada pieza, qué decisiones importan y qué frases conviene incluir en su prompt. Para las reglas de acceso en sí, lea nuestra guía de la seguridad a nivel de fila en Supabase.
Qué hace y qué no hace Supabase Auth
Supabase Auth demuestra quién es un usuario; no decide qué puede ver. Su documentación enumera los métodos de acceso: contraseña, enlace mágico, contraseña de un solo uso, inicio de sesión social (Apple, Google, GitHub y cualquier proveedor OAuth2 u OIDC), teléfono a través de proveedores como Twilio y inicio de sesión único empresarial con SAML. Los datos de usuario se guardan en un esquema especial de su propia base de datos Postgres.
Lo que un usuario puede hacer es una segunda capa. El cliente de Supabase envía el token del usuario con cada petición, y las políticas de seguridad a nivel de fila de la base de datos lo usan para filtrar las filas. La autenticación responde a "¿quién es?", y las políticas responden a "¿qué filas puede leer o modificar esta persona?". Una app con inicio de sesión pero sin políticas está abierta.
Qué método de acceso elegir
Elija el método que coincida con el comportamiento habitual de sus usuarios: Google para un público de consumidores o de startups, correo y contraseña para herramientas de empresa, enlace mágico cuando la gente inicia sesión pocas veces. Cada uno tiene un coste, resumido a continuación.
| Método | Adecuado para | Ventajas | Inconvenientes |
|---|---|---|---|
| Correo y contraseña | Herramientas de empresa, portales de clientes | Conocido, sirve con cualquier dirección de correo, sin terceros | Requiere correos de confirmación y de restablecimiento; los usuarios olvidan la contraseña |
| Enlace mágico o código por correo | Accesos poco frecuentes, clientes no técnicos | Sin contraseña que guardar ni olvidar | Cada inicio de sesión envía un correo, así que importan la entregabilidad y los límites de envío |
| OAuth (Google, GitHub) | Apps de consumo, startups, herramientas para desarrolladores | Un clic, sin flujo de restablecimiento de contraseña, sin correo que enviar | Hay que crear las credenciales del proveedor y registrar la URL de redirección; no todos los clientes tienen la cuenta |
| Código por teléfono | Mercados donde el teléfono es la identidad | Rápido en el móvil | Requiere una cuenta con un proveedor de SMS, que factura cada mensaje |
| SSO empresarial (SAML) | Venta a grandes empresas | Las empresas gestionan el acceso de forma centralizada | Configuración por cliente; compruebe los requisitos del plan en la página de precios de Supabase |
Confirmación por correo y restablecimiento de contraseña
Con la confirmación por correo activada, un usuario nuevo no puede iniciar sesión hasta que hace clic en el enlace del mensaje. La página de configuración de Supabase indica que, si la desactiva, el correo se considera confirmado sin ninguna comprobación. Manténgala activada en cualquier app con usuarios reales: sin ella, cualquiera puede crear una cuenta con una dirección que no es suya.
El restablecimiento de contraseña funciona igual: el usuario pide un enlace, recibe un correo y llega a una página de su app donde elige una nueva contraseña. Ambos flujos dependen de dos cosas que usted controla: los ajustes de redirección que verá más abajo y el remitente de los correos. Si un enlace de confirmación abre "localhost" o una página de error, la causa casi siempre está en los ajustes de redirección.
Sesiones: qué ocurre después del inicio de sesión
Tras el inicio de sesión, Supabase entrega al navegador un token de acceso de corta duración y un token de actualización, y la biblioteca cliente los renueva sin pedir al usuario que vuelva a iniciar sesión. Según la documentación de sesiones, el token de acceso es un JWT que caduca por defecto a la hora, y cada token de actualización solo puede usarse una vez. Si se reutiliza un token de actualización antiguo fuera de un breve margen, se cierra toda la sesión.
Para quien usa un creador de apps, lo práctico es que casi nunca escribe código de sesiones. Usted pide "mantener a los usuarios conectados" y "redirigir a la página de inicio de sesión cuando no haya sesión", y la app generada usa la biblioteca cliente para el resto.
auth.users frente a una tabla profiles
Deje el registro de acceso en auth.users y todo lo demás sobre la persona en una tabla propia, normalmente llamada profiles. La guía de Supabase sobre gestión de datos de usuario explica el motivo: el esquema auth no está expuesto en la API automática, así que su app no puede leerlo directamente. El patrón recomendado es una tabla pública profiles cuyo id referencia a auth.users con on delete cascade, con la seguridad a nivel de fila activada, y un trigger que crea la fila de perfil después de cada registro.
La misma guía advierte de que un trigger que falla puede bloquear los registros, así que pruébelo con una cuenta nueva real después de cada cambio en la tabla. Es una causa frecuente del error "Database error saving new user" cuando una IA modifica el esquema.
Roles: administrador, miembro, cliente
Guarde el rol en su propia tabla, no en el registro de acceso, y deje que la seguridad a nivel de fila lo haga cumplir. Una columna como role en profiles sirve para una sola organización. Cuando una misma persona puede pertenecer a varias empresas o espacios de trabajo, use en su lugar una tabla memberships (usuario, organización, rol), de modo que la misma persona pueda ser administradora en una y cliente en otra.
Ocultar un elemento del menú a los clientes no es seguridad: la base de datos debe rechazar la petición. Una política como "un cliente solo puede leer las facturas cuyo client_id coincide con su propia pertenencia" lo consigue. No permita nunca que los usuarios editen su propia columna de rol; la política de profiles debe permitir actualizar el nombre y el avatar, pero no el rol.
Registro solo por invitación para herramientas internas y portales
Para una herramienta interna o un portal de clientes, desactive el registro abierto y cree las cuentas solo por invitación. Supabase tiene un ajuste "Allow new users to sign up"; cuando está desactivado, solo pueden iniciar sesión los usuarios existentes. La invitación en sí, que crea al usuario, asigna el rol y envía el correo, debe ejecutarse en el servidor, en una edge function, porque necesita una clave secreta que nunca debe llegar al navegador.
El flujo que debe pedir: un administrador introduce un correo y un rol, el servidor crea el usuario y la fila de pertenencia, y la persona invitada recibe un enlace para fijar su contraseña. Nuestras guías sobre herramientas internas y portales de clientes muestran dónde encaja esto en una aplicación completa.
Site URL y URL de redirección
La Site URL es la dirección por defecto a la que Supabase devuelve a los usuarios, y las URL de redirección son una lista de otras direcciones permitidas. La documentación de URL de redirección indica que la Site URL empieza siendo http://localhost:3000 y debe cambiarse a su dirección de producción, porque de ella dependen las confirmaciones por correo y los restablecimientos de contraseña.
Añada todas las direcciones reales desde las que se sirve su app: su dominio de producción, su dominio propio si lo tiene y cualquier dirección de previsualización en la que haga pruebas. La documentación recomienda rutas exactas en producción y comodines sobre todo para el desarrollo local y las previsualizaciones. El fallo clásico es una app publicada cuyos correos siguen apuntando a localhost, o un dominio propio añadido más tarde y nunca registrado.
Límites de correo y SMTP propio
El servicio de correo integrado de Supabase es solo para pruebas: en noviembre de 2026 su documentación indica que está limitado a 2 mensajes por hora, entrega únicamente a las direcciones del equipo de su organización y no ofrece garantía de entrega. Esas cifras pueden cambiar sin aviso, así que lea la página de SMTP propio antes del lanzamiento.
Antes de que lleguen usuarios reales, conecte su propio proveedor (la página cita como ejemplos Resend, AWS SES, Postmark, SendGrid, ZeptoMail y Brevo). La misma página señala que el SMTP propio parte de 30 mensajes por hora, ajustables en la página de límites de frecuencia, y recomienda autenticar su dominio de envío con DKIM, SPF y DMARC. Si su primer usuario de prueba nunca recibe el correo de confirmación, esta es la razón, no un error de su app.
Cómo lo configura Cadrant
Cadrant, nuestro creador de apps, usa Supabase Auth en un proyecto de Supabase que pertenece a su propia cuenta de Supabase, así que las cuentas de usuario siguen siendo suyas. Según nuestra documentación de autenticación, genera las páginas de inicio de sesión y de registro, configura el registro con correo y contraseña, protege las rutas que exigen sesión y gestiona las sesiones. Los proveedores OAuth como Google los activa usted en el panel de Supabase, en Authentication, Providers.
La IA escribe las migraciones con seguridad a nivel de fila en las tablas por usuario y puede leer el esquema y las políticas actuales antes de modificarlos. Los roles se describen en el prompt y se guardan en columnas o tablas de su base de datos. Los secretos, como la clave de un proveedor de correo, se quedan en variables de entorno detrás de edge functions. Límites que conviene conocer: la Site URL, las URL de redirección, las credenciales de los proveedores y el SMTP propio son ajustes de Supabase que debe revisar usted mismo, y conviene probar cada rol a mano antes de invitar a clientes. Vea también nuestra visión general de Supabase con un creador de apps con IA.
Frases de prompt para pegar en su creador de apps
Describa a las personas y las reglas, no el código. Estas frases funcionan en la mayoría de los creadores:
- "Añade inicio de sesión con correo y contraseña y con Google. Los usuarios deben confirmar su correo antes de iniciar sesión."
- "Crea una tabla profiles vinculada a los usuarios de auth, rellenada automáticamente en el registro, con una columna role (admin, member, client). Los usuarios pueden editar su nombre pero nunca su rol."
- "El registro está cerrado. Solo un administrador puede invitar a un usuario por correo y elegir su rol, desde una función del servidor."
- "Un cliente ve solo sus propios registros. Un miembro ve a todo el equipo. Un administrador lo ve todo y gestiona a los usuarios. Aplica esto con seguridad a nivel de fila, no solo en la interfaz."
- "Añade un enlace de contraseña olvidada y una página para fijar una nueva contraseña. Redirige a los usuarios sin sesión a la página de inicio de sesión."