Autenticación en Supabase: email, magic link, OAuth, RLS | We.Inc
Código supabase-js v2 que funciona para email y contraseña, magic links, inicio de sesión con OAuth, listeners de sesión y cierre de sesión, además de políticas de row level security que usan auth.uid().
Supabase Auth permite iniciar sesión con email y contraseña, magic links de un solo uso, códigos por teléfono o proveedores OAuth como GitHub, todo a través del objeto supabase.auth de supabase-js. Cada inicio de sesión genera una sesión cuyo token llega a tu base de datos, donde las políticas de row level security comparan auth.uid() con una columna user_id para decidir qué puede leer esa persona.
Métodos de inicio de sesión y la llamada de cada uno
Método
Llamada en supabase-js v2
Ideal para
Email y contraseña
auth.signUp / auth.signInWithPassword
Cuentas clásicas
Magic link
auth.signInWithOtp({ email })
Sin contraseñas que olvidar
Código por SMS o WhatsApp
auth.signInWithOtp({ phone })
Productos pensados para móvil
Proveedor OAuth
auth.signInWithOAuth({ provider })
Inicio de sesión con un clic usando una cuenta existente
Cerrar sesión
auth.signOut()
Terminar la sesión
La autenticación es la parte de un proyecto Supabase que más a menudo se conecta mal: el inicio de sesión funciona, pero los datos quedan expuestos o el servidor confía en una cookie en la que no debería. Elige un método abajo para obtener su código y luego sigue la sección de políticas para que cada persona solo vea sus propias filas.
Elige un método de inicio de sesión en el selector de código y copia el fragmento en tu app.
Activa el proveedor correspondiente en el panel de Supabase y añade la dirección de tu sitio a las URL de redirección permitidas.
Escucha los eventos de autenticación para que tu interfaz se actualice cuando alguien inicia o cierra sesión.
Activa row level security en cada tabla con datos personales y añade políticas que usen auth.uid().
Con la confirmación por email activada, signUp devuelve un usuario pero una sesión null hasta que se hace clic en el enlace, así que muestra un mensaje de revisa tu bandeja de entrada en lugar de un dashboard.
Envuelve la función como (select auth.uid()) dentro de las políticas. Así Postgres puede evaluarla una vez por sentencia en lugar de una vez por fila.
auth.uid() es null en las peticiones sin un usuario con sesión iniciada, así que una política que lo compara con user_id simplemente no coincide con nada para los visitantes anónimos.
En el servidor, no te fíes de getSession() leído de las cookies; usa getUser() o getClaims() para verificar quién pregunta.
La clave publicable (anon) es segura en el navegador porque las políticas la limitan. Una clave secreta o service role se salta row level security y debe quedarse en el servidor.
Preguntas frecuentes
¿El magic link de Supabase es lo mismo que un OTP?
Los dos parten de signInWithOtp. En el email, el mensaje lleva un enlace cuando la plantilla usa la URL de confirmación y un código cuando usa el token. El inicio de sesión por teléfono solo admite códigos, por SMS o WhatsApp.
¿Cómo añado inicio de sesión con Google o GitHub?
Activa el proveedor en el panel con el client ID y el secret de ese proveedor, y luego usa signInWithOAuth con su nombre y una dirección redirectTo opcional. La persona vuelve a tu sitio con la sesión ya iniciada.
¿Cómo sé cuándo un usuario inicia o cierra sesión?
Registra onAuthStateChange. Informa de eventos como INITIAL_SESSION, SIGNED_IN, SIGNED_OUT, TOKEN_REFRESHED, USER_UPDATED y PASSWORD_RECOVERY, y devuelve una suscripción que debes cancelar cuando el componente se desmonta.
¿Por qué los usuarios con sesión no ven nada después de activar RLS?
Una vez activado row level security, la tabla lo deniega todo hasta que una política lo permita. Añade una política select para el rol authenticated que compare (select auth.uid()) con la columna del propietario.
¿Debo usar Supabase Auth o Firebase Auth?
Los dos cubren los métodos habituales. La diferencia más grande es la base de datos que hay debajo; nuestra comparativa Supabase vs Firebase repasa esa elección en detalle.
Sesiones y tokens
Tras el inicio de sesión, supabase-js guarda un access token de corta duración y un refresh token, y renueva el access token automáticamente. Cada consulta que haces con el mismo cliente envía el access token, que es como Postgres conoce el ID del usuario.
En las apps renderizadas en servidor, la sesión vive en cambio en cookies. La guía de autenticación con Next.js de este sitio cubre esa conexión, así que esta página se centra en la librería de cliente y en las reglas de la base de datos.
Row level security es el cerrojo de verdad
Ocultar un botón en la interfaz no protege los datos, ya que cualquiera puede usar tu API con la clave pública. Las políticas se ejecutan dentro de Postgres en cada petición, y por eso son el lugar donde se impone la propiedad de los datos.
Escribe una política por acción. Una política select usa using, mientras que insert necesita with check para que nadie pueda crear filas a nombre de otra persona, y update suele necesitar ambas.
Políticas que usan auth.uid()
Cada persona lee y escribe solo sus propias notas
Ejecútalo en el editor SQL. El valor por defecto rellena user_id a partir del token, y with check impide que alguien inserte filas para otro usuario.
Email y contraseña
Crea la cuenta y luego inicia sesión. Con la confirmación activada, data.session es null hasta que se hace clic en el enlace del email.
Magic link
Envía un email cuyo enlace inicia la sesión de la persona y la lleva a la dirección de redirección.
OAuth (GitHub)
Redirige al proveedor y de vuelta. Antes, activa el proveedor y configura sus claves en el panel.
Listener de sesión y cierre de sesión
Mantiene la interfaz sincronizada con la sesión y limpia el listener cuando terminas.