Cuando alguien dice “vamos a montar OAuth2 con Google”, la mayoría de desarrolladores piensan: “Bah, 10 minutos. Un par de endpoints, copio el client_id y a correr”.
Y una mierda.
La realidad te va a dar una bofetada en la cara más pronto que tarde. Operar autenticación en producción es uno de los marrones más grandes que te puedes comer, y mucha gente no se da cuenta hasta que tiene el agua al cuello.
Hoy en día hay dos religiones para resolver esto:
- Delegar el problema a un gigante como Auth0.
- Hacerte el valiente y operarlo tú mismo con Supabase Auth, el antiguo GoTrue.
Las dos valen y las dos tienen coste, pero una te cobra en euros y la otra te puede cobrar en ansiedad y noches sin dormir.
Este post no es para venderte nada. Es para que entiendas dónde te estás metiendo.
Qué es Supabase Auth realmente (sin marketing)
Supabase Auth es el servicio de identidad del ecosistema Supabase. Por debajo hay un servidor de autenticación open source que hace lo que promete: gestionar usuarios, emitir JWTs y hablar con proveedores como Google o GitHub.
Lo vas a ver citado como GoTrue por todas partes, pero ese nombre ya no es el vigente: el repositorio y la imagen se llaman ahora supabase/auth. La vieja supabase/gotrue sigue publicada y no se rompe nada, pero las variables de entorno mantienen el prefijo GOTRUE_, y esa mezcla despista.
Cuando usas Supabase gestionado, ellos lo operan. Pero si te vas a Supabase Auth self-hosted (porque eres un “hacker” y no quieres pagar la nube), ese servidor es tuyo.
Y “tuyo” significa:
- Tu base de datos de identidades.
- Tus secretos JWT.
- Tus flujos OAuth que se rompen cuando Google cambia la API.
- Tu responsabilidad legal.
No hay un panel de control mágico como en Auth0. Aquí se juega con Docker Compose y variables de entorno.
El setup “mínimo viable” ya asusta un poco si lo miras con lupa:
services:
auth:
image: supabase/auth:v2.194.0
environment:
GOTRUE_DB_DRIVER: postgres
GOTRUE_DB_DATABASE_URL: postgres://postgres:password@db:5432/auth
GOTRUE_JWT_SECRET: un-secreto-que-seguro-copiaste-de-stackoverflow
GOTRUE_EXTERNAL_GOOGLE_ENABLED: "true"
# ... 50 variables más para que esto sea seguro de verdad
Funciona. Y funciona muy bien. Pero aquí empieza la parte que nadie te cuenta en los tutoriales de “Clon de Netflix en 10 minutos”.
Autenticar no es solo “hacer login”
Cuando te montas tu propio chiringuito de auth, te conviertes automáticamente en el Director de Seguridad, Cumplimiento y Operaciones de tu empresa. Felicidades por el ascenso (sin sueldo).
Ahora eres responsable de:
1. Seguridad (la de verdad)
- La custodia de claves. Si te roban el
GOTRUE_JWT_SECRET, has comprometido a todos tus usuarios. Tienes que rotarlo. ¿Sabes rotar claves sin tirar el servicio? - Los ataques. Rate limiting, protección contra fuerza bruta, enumeración de usuarios… El servidor trae cosas de serie, pero configurarlas bien es tarea tuya.
2. Privacidad y legalidad
- Datos personales, emails, IPs, consentimientos.
- El derecho al olvido. Cuando un usuario pide borrarse, tienes que borrarlo de verdad. De todos lados.
- Logs: ¿estás logueando información sensible? Multa al canto.
3. Disponibilidad
Si tu Postgres de auth se cae, no entra nadie y tu producto deja de existir para todo el mundo a la vez. Tienes que tener backups, réplicas y un plan de recuperación ante desastres que no sea “llorar en un rincón”.
Por qué existe Auth0 (y por qué es tan caro)
Auth0 no existe para darte OAuth2. Existe para absorber tu riesgo.
Cuando contratas Auth0, estás pagando (y bien pagado) por tranquilidad operativa:
- Ellos guardan las contraseñas y las hashean mejor que tú.
- Las claves las rotan ellos.
- Se pelean con las auditorías SOC2 y la ISO 27001 en tu lugar.
- Monitorizan ataques globales y bloquean IPs maliciosas antes de que lleguen a ti.
Tú te dedicas a construir tu producto. Ellos se dedican a que nadie entre donde no debe.
Es caro, sí. Pero, ¿cuánto vale tu tiempo si tienes una brecha de seguridad un sábado a las 3 de la mañana?
La comparativa brutal
Vamos al grano, con lo bueno y lo malo de cada uno.
Antes de la tabla, una aclaración: aquí comparo Supabase Auth self-hosted contra Auth0 gestionado, que es como se plantea la decisión casi siempre. Pero hay un tercer camino que conviene no olvidar. Supabase Auth también existe gestionado, y en cuanto lo operan ellos se cae media columna: la operación, buena parte del riesgo y casi todo el cumplimiento dejan de ser tuyos. Eso no cambia la tesis de este post, porque el coste de operar identidad se sigue subestimando; lo que cambia es que puedes decidir no operarla sin cambiar de producto.
| Supabase Auth (self-hosted) | Auth0 | |
|---|---|---|
| Precio | Gratis, o lo que te cueste tu infraestructura | Caro, y el precio escala muy rápido si tienes éxito |
| Control | Total: tu código, tu base de datos, tus reglas | El que te dé su panel: la infraestructura no la tocas |
| Riesgo | También total: todo es culpa tuya y, si falla, lo arreglas tú | Lo absorben ellos; para eso existe el producto |
| Operación | Claves, backups, réplicas y actualizaciones: un trabajo en sí mismo | Rotan claves, monitorizan ataques y bloquean IPs por ti |
| Cumplimiento | El GDPR pasa a ser tu problema, no el de ellos | Se pelean con SOC2 e ISO 27001 en tu lugar |
| Dependencia | Ninguna: es open source, y si Supabase desaparece tú sigues vivo | Total: si Auth0 se cae (pasa poco, pero pasa), estás vendido |
| Madurez | La que tenga tu equipo | Es el estándar: funciona y punto, y aguanta lo que le eches |
| Encaje | Se lleva de maravilla con tu backend, sobre todo si ya usas Postgres | Servicio externo: la identidad vive fuera de tu base de datos |
La columna de Supabase asume self-hosted. Con Supabase gestionado, las filas de operación, riesgo y cumplimiento se parecen mucho más a las de Auth0.
La pregunta del millón
La decisión no es técnica. No va de “¿qué tecnología mola más?”.
La pregunta correcta es si quieres, y sobre todo si puedes, asumir el riesgo de operar identidad en producción.
Hay contextos donde Supabase Auth es la opción sensata:
- Producto pequeño o mediano.
- Equipo técnico fuerte que sabe de seguridad.
- Necesitas control granular y presupuesto ajustado.
- Entorno no regulado al extremo.
Y hay contextos donde Auth0 es obligatorio:
- SaaS B2B vendiendo a empresas grandes (Enterprise).
- Datos muy sensibles (salud, financiero).
- Auditorías de seguridad externas requeridas.
- Cero tolerancia a caídas o incidentes.
Delegar la autenticación no te hace peor programador ni “menos hacker”. Es gestión de riesgo, que es una cosa distinta.
Al final la autenticación es la puerta de tu casa. Tú decides si pones un portero de discoteca profesional o le das la llave a tu primo y rezas para que no la pierda.
