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:

  1. Delegar el problema a un gigante como Auth0.
  2. Hacerte el valiente y operarlo tú mismo con Supabase Auth (GoTrue).

Ambas valen. Ambas tienen costes. 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 es GoTrue, un servidor de autenticación open source que hace lo que promete: gestionar usuarios, emitir JWTs y hablar con proveedores como Google o GitHub.

Cuando usas Supabase gestionado, ellos lo operan. Pero cuando usas 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/gotrue:latest
    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)

  • Custodia de claves: Si te roban el JWT_SECRET, has comprometido a todos tus usuarios. Tienes que rotarlo. ¿Sabes rotar claves sin tirar el servicio?
  • Ataques: Rate limiting, protección contra fuerza bruta, enumeración de usuarios… GoTrue tiene cosas, pero tú tienes que configurarlas bien.

2. Privacidad y Legalidad

  • Datos personales, emails, IPs, consentimientos.
  • 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, nadie entra. Nadie usa tu producto. El impacto es total. 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ú.
  • Ellos rotan las claves.
  • Ellos se pelean con las auditorías SOC2 y la ISO 27001.
  • Ellos 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. Sin paños calientes.

Supabase Auth (Self-hosted)

Lo bueno:

  • Control total: Es tu código, tu base de datos, tus reglas.
  • Precio: Gratis (o el coste de tu infraestructura).
  • Open Source: Sin vendor lock-in. Si Supabase desaparece, tú sigues vivo.
  • Integración: Se lleva de maravilla con tu backend, especialmente si usas Postgres.

Lo malo:

  • Riesgo total: Todo es culpa tuya. Si falla, tú lo arreglas.
  • Complejidad operativa: Mantener esto seguro y actualizado es un trabajo en sí mismo.
  • Compliance: El GDPR es tu problema, no el de ellos.

Auth0

Lo bueno:

  • Madurez: Es el estándar. Funciona y punto.
  • Seguridad gestionada: Duermes tranquilo sabiendo que hay un equipo de seguridad de élite vigilando.
  • Escalabilidad: Aguanta lo que le eches.

Lo malo:

  • Te va a doler la cartera: El pricing puede escalar muy rápido si tienes éxito.
  • Dependencia: Si Auth0 se cae (que pasa poco, pero pasa), estás vendido.

La pregunta del millón

La decisión no es técnica. No es “¿qué tecnología mola más?”.

La pregunta correcta es:

¿Quieres (y 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 es ser peor programador o ser “menos hacker”. Es gestión de riesgo.

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.