¿Qué es Supabase Auth y cómo funcionan sus usuarios y sesiones?
Publicado el 2026-10-20 por frfrand
Supabase Auth explicado: login, registro, JWT, sesiones, refresh token, recuperación de cuenta y relación con las políticas RLS.
Supabase Auth es el servicio de Supabase que ayuda a registrar usuarios, verificar su identidad y mantener sesiones dentro de una aplicación. Permite implementar métodos como correo y contraseña, enlaces mágicos y determinados proveedores externos sin escribir todo el mecanismo de autenticación desde cero.
Pero cuidado: autenticar no es lo mismo que autorizar. Saber quién es una persona no significa que tenga permiso para consultar todos los datos de tu proyecto.
El ejemplo de la biblioteca
Imaginá una biblioteca con tarjetas de socio. Mostrar la tarjeta permite que el personal sepa quién sos, pero eso no significa que puedas abrir el armario de administración o llevarte un libro reservado para otra persona.
En una aplicación ocurre algo parecido: el login identifica al usuario; las reglas de autorización deciden a qué datos y operaciones puede acceder.
Supabase Auth proporciona piezas para la primera parte y se integra con capacidades de PostgreSQL, como RLS, para apoyar la segunda.
¿Qué pasa cuando alguien inicia sesión?
En un flujo habitual, el cliente envía credenciales a un servicio de autenticación. Si se verifican, puede recibir datos de sesión y tokens que utilizará en peticiones posteriores.
Supabase utiliza JWT, o JSON Web Tokens, para representar cierta información de identidad y sesión. Un JWT firmado permite al receptor comprobar su validez siguiendo las reglas del sistema.
El token no debería confundirse con una contraseña ni con una garantía de que cualquier solicitud está autorizada. También hay que validar su emisor, vigencia, firma y propiedades esperadas.
¿Qué es un access token?
Es una credencial que el cliente utiliza durante un período limitado para demostrar que dispone de una sesión válida.
Cuando una aplicación realiza una petición a los servicios de Supabase, las bibliotecas pueden gestionar el envío del token correspondiente.
El servidor o base utiliza esa identidad dentro de sus mecanismos de autorización. Por ejemplo, una política RLS puede permitir que la persona consulte solamente sus propias reservas.
¿Y el refresh token?
Sirve para solicitar nuevas credenciales de acceso sin pedirle la contraseña al usuario en cada operación.
La duración, renovación y revocación de sesiones depende de la configuración. No conviene copiar valores de una guía antigua sin revisar la documentación de la versión actual.
También hay que decidir qué pasa al cerrar sesión, cambiar contraseña o detectar un dispositivo comprometido.
¿Dónde se guardan los tokens?
Depende de la arquitectura. Una aplicación de navegador, una app móvil y un backend tradicional no necesariamente deben gestionar sesiones de la misma manera.
Guardar credenciales en lugares accesibles a JavaScript implica consideraciones ante ataques XSS. Utilizar cookies también requiere estudiar atributos, políticas de origen y protección frente a ciertas solicitudes no deseadas.
Lo importante es elegir un patrón recomendado para tu framework y comprender sus riesgos, no mover tokens de un lugar a otro porque un tutorial dijo que es «más seguro».
¿Qué es un enlace mágico?
En vez de ingresar una contraseña tradicional, el usuario recibe un enlace de acceso enviado a su correo. El sistema valida ese enlace bajo condiciones definidas.
Es cómodo, pero la seguridad depende mucho de la cuenta de correo y de cómo se protejan y caduquen los enlaces. Si alguien controla el correo de la persona, puede intentar aprovechar métodos de recuperación o acceso.
¿Supabase Auth reemplaza toda la lógica de usuarios?
No necesariamente. Puede gestionar identidad y sesiones, mientras que tu aplicación mantiene perfiles, preferencias, roles comerciales y otras tablas.
No conviene utilizar directamente las tablas internas del sistema de autenticación como si fuesen tu modelo completo de negocio. Seguí los mecanismos soportados para enlazar identidades con datos de aplicación.
¿Cómo interviene RLS?
Cuando una solicitud llega con una identidad verificada, PostgreSQL puede aplicar políticas que limiten filas visibles o modificables.
Una política de lectura no protege automáticamente todas las operaciones. También hay que revisar permisos SQL y claves privilegiadas. En particular, nunca publiques secretos administrativos en el frontend.
¿Cuándo conviene utilizar Supabase Auth?
Resulta útil si tu aplicación ya trabaja con el ecosistema Supabase y necesita login, sesiones y permisos de acceso a datos.
Si tenés un backend completo con un sistema de usuarios consolidado, quizás convenga integrar ese sistema en lugar de mantener dos fuentes de identidad innecesariamente.
¿Y en ArduMaker?
Si alojás un backend propio o bases PostgreSQL en VPS de ArduMaker, podés implementar autenticación mediante herramientas apropiadas para tu arquitectura. Supabase Auth es una opción externa distinta, no una función que deba asumirse disponible por defecto en cualquier PostgreSQL.
En resumen: Supabase Auth resuelve gran parte de la autenticación; tu aplicación sigue necesitando autorización, sesiones seguras y diseño correcto de permisos.
Fuentes: Documentación de Supabase Auth · Sesiones de Supabase · JWT en Supabase.