Por qué no deberías construir tu propio sistema de autenticación: lecciones de docenas de entrevistas con clientes
Puedes construir tu propio sistema de autenticación en un día, y puede funcionar durante años. El coste real aparece después, el día que tu negocio cambia. Lecciones de docenas de entrevistas B2B.
YijunDeveloper
Deja de perder semanas en la autenticación de usuarios
Lanza aplicaciones seguras más rápido con Logto. Integra la autenticación de usuarios en minutos y concéntrate en tu producto principal.
La autenticación parece algo que puedes resolver por ti mismo. Correo electrónico, contraseña, la almacenas hasheada, la comparas en el login. ¿Qué tan difícil puede ser construir tu propio sistema de autenticación?
Puedes hacerlo. Esa es la trampa.
Hemos hablado con docenas de equipos sobre la autenticación que construyeron por sí mismos. La mayoría nos contactó por el mismo motivo: estaba frenando el negocio.
Distintas industrias, tecnologías y tamaños, pero siempre el mismo desenlace. La autenticación que crearon se había convertido en una deuda que el equipo cargaba a cuestas.
Lo curioso es que nunca se manifiesta como una caída del sistema. El sistema sigue permitiendo iniciar sesión a los usuarios y funciona bien, hasta que un cambio empresarial bloquea el camino: una auditoría de seguridad, el primer cliente empresarial, una adquisición, una funcionalidad que conecta dos productos.
La semana pasada estaba "bien". Luego, lo siguiente en la hoja de ruta se quedó atascado detrás de eso.
El mayor error con la autenticación casera es tratarla como una característica más. Puedes escribir el código el primer día. Pero en cuanto el tráfico real pasa a través de él, se enreda con usuarios, organizaciones y permisos.
La autenticación no es una característica cualquiera. Es infraestructura de identidad.
Detrás de la página de login hay todo un modelo de identidad#
Todos los sistemas de autenticación caseros empiezan igual. Tomas un correo electrónico y una contraseña, los almacenas hasheados, los comparas en login. Cuarenta líneas de código, limpio y listo.
Los problemas empiezan después del lanzamiento. Los bots saturan el endpoint de registro, así que añades limitación de peticiones, un CAPTCHA, huellas digitales de dispositivos. Los códigos SMS dejan de enviarse una mañana, así que agregas reintentos y un límite diario. Luego llegan las partes difíciles: recuperación segura de contraseñas, MFA y su flujo de recuperación, sesiones y refresh tokens, y un modelo de permisos que va mucho más allá de un booleano is_admin.
Nada de eso es difícil por sí solo. Cada cosa cabe en un sprint. Pero cada vez que implementas una, respondes una pregunta mayor por el producto.
Si apilas todas esas respuestas, tienes el modelo de identidad que tu producto ahora asume silenciosamente que es real: quién cuenta como usuario, si una persona puede pertenecer a varias organizaciones, cómo se conecta el sistema de identidad de un cliente empresarial, y cómo se revoca el acceso cuando alguien se va.
Cada funcionalidad que escribas después tratará esas respuestas como dadas, y mientras más tiempo pase, más difícil será cambiarlas.
Vimos esto en una empresa: una SaaS vertical B2B, veinte años en el mercado, atendiendo a tiendas físicas. Construyeron su propia autenticación hace más de una década, con un login independiente por cliente y validaciones de permisos codificadas directamente en los módulos de negocio. Era una decisión razonable en su momento.
Veinte años después, querían algo que suena pequeño: una página de login unificada, usando correo electrónico como usuario. No era simplemente cambiar una página. Esas validaciones se habían esparcido por cientos de módulos, y unificar el inicio de sesión significaba tocar el modelo de usuario, el modelo de la organización, la migración de credenciales y todos los límites de permiso. Nadie quería aprobar ese cambio, así que se prolongó durante años.
Cuando escribieron esa primera página de login, parecía una característica. Lo que quedó atrás fue todo un modelo de identidad.
Cuando tu negocio avanza, la autenticación casera suele dejar de ser suficiente#
Siendo justos, la autenticación casera suele funcionar durante mucho tiempo. Permite entrar, refresca sesiones y sostiene el negocio diario durante años. Su complejidad se acumula lento, nunca de golpe, y la gestionas poco a poco creyendo que lo tienes bajo control.
Pero seguir siendo "suficiente" a menudo sólo significa que el negocio aún no ha chocado con la pared. Cuando eso ocurre, el problema normalmente no es la autenticación per se. El negocio alrededor cambia, y lo "suficiente" se convierte en un obstáculo de la noche a la mañana.
Las situaciones siguientes suelen aparecer en la mayoría de productos a medida que escalan. Parecen diferentes, pero en el fondo son lo mismo: el negocio avanzó y el modelo de identidad antiguo no puede seguir el ritmo.
El escenario: un cliente quiere iniciar sesión con su propio proveedor de identidad (IdP), y tu sistema de autenticación no tiene ningún concepto de "un proveedor de identidad externo".
Llega el primer trato empresarial real, y compras te envía un documento de requisitos. Primero es SSO mediante Microsoft Entra o Google Workspace. Luego tienes que soportar SAML y OIDC, porque el siguiente cliente usa otra cosa. Después es SCIM, para provisionar y desprovisionar empleados automáticamente.
Cada cliente configura diferente: distintos protocolos, mapeos de campos, rotación de certificados y maneras en que su estructura organizacional se asocia a la tuya.
Y casi nada de ese trabajo se puede reutilizar. Cada cliente nuevo trae un IdP distinto y una configuración fresca: casi siempre es empezar de cero. SSO no es una característica que construyes una vez. Cada gran cliente que firmas, lo vuelves a reconstruir, y el coste sólo crece con el número de clientes.
La autenticación dejó de ser "deja que los usuarios accedan a tu producto". Ahora es "haz que tu producto se conecte al sistema de identidad del cliente". Son dos trabajos completamente diferentes.
Vimos una empresa donde toda la configuración de SSO se hacía a mano y sólo un ingeniero entendía todo el proceso. Si él estaba, los clientes podían activarse. Si se tomaba unas vacaciones, ventas y onboarding se quedaban atascados. Cuando se fue, el conocimiento se marchó con él.
Nada de esto estaba sobre la mesa el día que decidieron construir su propia autenticación.
El producto necesita unificar una identidad que está dispersa#
El escenario: tu información de identidad empezó fragmentada, separada por organización y por producto, y a medida que tu negocio crece empiezas a necesitar una identidad unificada.
La empresa de veinte años mencionada antes lo vivió cuando intentó unificar su login, y el mismo patrón se repite en muchos productos. Trabajamos con una plataforma que tenía nueve productos, todos provenientes de adquisiciones, cada uno con su propia autenticación y almacenamiento de usuarios.
Una adquisición no fusiona eso automáticamente. Cada producto que compras trae su propio stack de autenticación y mantener nueve en paralelo exige el tiempo completo de personas.
Las preguntas se acumulan. ¿Es la misma persona un solo usuario en los productos A y B o son dos? ¿Cómo alinear la misma organización en ambos? ¿Cómo autorizas una funcionalidad cruzada? Cuando un empleado se va, ¿cómo le revocas el acceso en los nueve a la vez? ¿Y dónde auditas esto?
Ninguno de los nueve está roto. Juntos, forman un muro.
"Unificar identidad" suena como una funcionalidad. En código, significa redefinir lo más fundamental: qué cuenta como un usuario y una organización. Casi todas las funcionalidades dependen de esa definición antigua, así que cambiarla mueve toda la capa superior.
En la era de la IA, agentes y CLIs acceden a tu sistema en nombre del usuario#
El escenario: ya no sólo son personas iniciando sesión desde un navegador. Ahora agentes, comandos y scripts actúan en nombre de usuarios, mientras tu autenticación sólo sabe manejar a una persona en una página de login.
Un agente necesita llamar a tus herramientas internas por un usuario. Un servidor MCP debe exponer recursos protegidos de forma segura. Una CLI necesita acceder a datos de cuenta sin usar navegador.
Los tres plantean las mismas preguntas: ¿para qué usuario actúa esta petición?, ¿a qué recursos puede acceder?, ¿a quién se le emite el token?, ¿cuál es su alcance (scope)?, ¿cómo lo revocas?, ¿registras al usuario o al agente?
El sistema antiguo nunca construyó los mecanismos que estos clientes necesitan. MCP depende de OAuth para la autorización. Una CLI pasa por login OAuth o usa un token de acceso personal que puede ser revocado en cualquier momento. Nada de esto se hizo pensando en una página de login.
Si tu autenticación fue diseñada para una sola persona en la web, ahora tienes que manejar clientes que actúan en nombre de esa persona.
El mayor coste de construir tu propia autenticación es el mantenimiento a largo plazo#
Ninguno de los escenarios anteriores es "la autenticación se cayó". El sistema sigue funcionando. Cada uno parece una característica pequeña, y cuando empiezas, se convierte en estrategia de producto, migración de datos y trabajo de entrega al cliente.
El caso más claro es el MFA (autenticación multifactor). Por fuera parece "¿podemos verificar algo más luego de login?"
Y a los dos pasos ya es: ¿a qué orgs y usuarios los fuerzas a usarlo?, ¿un admin puede exigirlo a sus miembros?, ¿acciones sensibles como cambiar el pago o exportar datos requieren otro chequeo?, ¿cómo generas y restableces códigos de recuperación?, ¿puede soporte restablecerlos?, ¿y el MFA de un usuario SSO es tuyo o del IdP del cliente? Implementar MFA es introducir todo un nivel nuevo de política de seguridad.
"Sólo sincroniza algunos usuarios" es la misma historia: detrás hay una cadena de decisiones sobre onboarding, offboarding y membresía cruzada entre organizaciones, cada una asumiendo que tu modelo de usuario y organización se diseñó bien de entrada.
Cuantas más funcionalidades implementes, más estarás manteniendo un producto de identidad dentro de tu propio producto. La primera versión es barata, unos cuantos ingenieros y unas semanas. Pero lo alimentas año tras año.
El coste oculto: la factura sólo cambió su forma de cobrarse#
La razón típica para construir tu propio sistema es el coste, y no es ingenua.
Una organización de membresía que entrevistamos hizo los cálculos hace cinco años. Tenían cien mil socios, pero solo unos pocos miles iniciaban sesión regularmente. Los proveedores cobraban por el total de miembros, la propuesta superaba por mucho el presupuesto, y construyéndolo por su cuenta salía más barato. Ese año, no fue una mala decisión.
Cinco años después, las cuentas se dieron la vuelta. Mantener su propio sistema y hacerlo seguro resultó más caro que comprarlo hecho.
En el primer año, la factura que ahorras es visible y el tiempo del equipo no. Cinco años después, el ahorro sigue igual pero el tiempo de ingeniería se convirtió en retrasos, deuda de seguridad y mantenimiento que nadie quiere asumir.
Así que construir tu propia autenticación no es gratis. Simplemente nunca recibes una factura que diga "suscripción de autenticación". La pagas en meses-persona, plazos incumplidos, re-trabajo, deuda de seguridad y la atención que tus ingenieros ya no pueden dedicar a lo esencial.
Ese ingeniero que mantenía el SSO a mano no es una excepción. Si ejecutas autenticación casera tiempo suficiente, todo el contexto crítico recae en una o dos personas: qué cliente tiene qué configuración, qué campo no puedes tocar, por qué se hizo cierta migración. Rara vez queda documentado. Está en la cabeza de alguien.
Cuando él está, la entrega fluye. Cuando no, la implementación empresarial se detiene, y descubres que tu infraestructura más importante no tiene dueño, solo "la persona que sabe".
Algunos equipos van más lejos y construyen para sus clientes una plataforma de autoconfiguración de SSO. Suena maduro, hasta que preguntas cuántos clientes la usan. Vimos uno con 1,5 millones de usuarios activos al mes manteniendo todo un sistema así para apenas una docena de clientes.
Pensabas que estabas construyendo una funcionalidad. Construiste un producto interno, con el coste repartido entre una docena de clientes. Si tu negocio es la identidad, vale la pena. Si no, es la factura oculta más pura.
Volvamos a la SaaS vertical de veinte años. No son ingenieros mediocres. Mantener un producto durante veinte años es justo lo que prueba que conocen a sus clientes.
Ese es todo el problema. En corto: ¿los quieres manteniendo a mano el SSO de cada cliente y sacando veinte años de lógica de permisos de cientos de módulos, o profundizando en el software de la industria?
No es perfeccionismo ingenieril. Es asignación de recursos. Si desarrollas sistemas de pago, SaaS vertical, portal de membresía o software operativo, ningún cliente te paga más por crear tu propio servidor OAuth.
Un equipo de pagos lo dijo claro: su IdP casero estaba bien, pero es una decisión estratégica. No escribas mucho código para autenticación. Guarda esa energía para hacer el pago lo mejor posible y usa la solución de autenticación más probada para lo demás.
La autenticación debe ser confiable. Pero "confiable" no es lo mismo que "hecha por ti". Tu base de datos, el correo electrónico y la nube también deben ser confiables, y un equipo maduro no asume que algo merece estar hecho en casa solo porque es importante.
Para la mayoría de productos, la autenticación es una dependencia crítica, no un diferenciador. A menos que la identidad sea tu negocio, mantener un producto de identidad propio normalmente no es una ventaja. Es un lastre a largo plazo.
¿Cuándo todavía tiene sentido construir tu propia autenticación?#
Es fácil caer en el extremo de "nunca escribir código de autenticación". Eso también está mal.
En ciertas etapas, construir tu propia (o parte) tiene mucho sentido: demos internas, prototipos muy tempranos, pruebas de concepto. Y si tu negocio requiere autorización de una granularidad particular que las plataformas disponibles no pueden cubrir, mantener esa parte interna, mientras delegas autenticación, sesiones, SSO, MFA y directorio de usuarios a una plataforma externa, es válido.
Solo ten cuidado con la pendiente del POC. Hemos visto el patrón típico: dos desarrolladores gastan seis a ocho meses en un prototipo para integrarse a un sistema externo. El enfoque no es malo. Ellos mismos dicen que la cosa funciona bien. Pero nunca estuvo pensado para escalar.
Y un POC es lo más fácil de convertir en arquitectura duradera. A los seis meses es "la solución actual", dos años después "el sistema legado", cinco años después "infraestructura intocable". El mejor momento de dejar la autenticación casera normalmente no es cuando falla, sino antes de que se asiente como base.
Así que la línea es ésta: la cuestión no es si has escrito código de autenticación. Es si has absorbido una pieza genérica de infraestructura de identidad y la mantienes internamente a largo plazo.
Construye capacidades específicas tú mismo. Ten cuidado con la capa de identidad central. Y no te encuentres, sin darte cuenta, montando tu propia plataforma CIAM.
Si no lo construyes, ¿cómo eliges una solución de autenticación?#
Si decides no construirlo tú mismo, la siguiente pregunta es: ¿de quién lo compras y cómo eliges?
Las soluciones maduras ya cubren las funcionalidades: SSO, MFA, varias organizaciones, login unificado, acceso de agentes. Así que la diferencia real rara vez está en la columna de funcionalidades.
Lo más fácil de pasar por alto, y más importante de comparar, son los siguientes puntos. Todos son fachadas del mismo objetivo: que no termines saliendo de los miles de líneas que tú mismo escribiste para acabar atrapado en otro sistema del que no puedes salir.
Apegarse a protocolos estándar, no a un stack inventado por un proveedor. OIDC, OAuth y JWTs firmados con RS256 son cosas que ya entiendes. Lees las claims directamente del token habitual, sin una API propietaria.
Que siempre quede una puerta abierta. Si la solución es open source y auto hospedable, puedes marcharte si lo necesitas. (Por supuesto, mantener una versión auto hospedada tiene su propio coste oculto a largo plazo).
No dejes que la facturación dependa de tu tabla de usuarios. Cobrar por usuarios registrados o activos mensuales hace que la tabla solamente crezca, llena de inactivos, y en escala se convierte en un "impuesto al crecimiento". Ese es el precio que empujó a la organización de membresía anterior a construir su propio sistema.
Tus datos no quedarán atrapados. Puedes exportar los datos de usuarios cuando quieras. Y entregar estos datos sensibles a un host especializado te ahorra el riesgo de guardar datos privados que nunca debiste custodiar.
Transparencia total: Logto es el producto de autenticación que creamos cumpliendo justo estos cuatro puntos. Es de código abierto, auto hospedable y también en versión cloud gestionada: usa Cloud para cero mantenimiento o auto hospedaje si quieres control total. El día que quieras irte, la puerta queda abierta.
Inicio de sesión, MFA, SSO y RBAC funcionan listos sobre OIDC estándar, y la facturación sigue los tokens, así que pagas solo por lo que usas.
Hay más opciones maduras, y la autenticación nunca tuvo una sola respuesta correcta. Si quieres evaluarlas, escribí sobre cómo elegir una solución de autenticación que te puede servir.
Conclusión: no confundas una plataforma de identidad con una característica ordinaria#
Construir tu propia autenticación suele ser razonable el primer día. El truco es que luego crece hasta ser infraestructura.
Cada paso adelante del negocio la vuelve a poner a prueba: las empresas piden SSO, seguridad exige MFA, el producto quiere login unificado, múltiples productos deben conectarse, los agentes de IA quieren acceder a recursos por el usuario. Detrás de cada funcionalidad pequeña hay una serie de decisiones de política, y alimentarla con los años consume el tiempo ingenieril que debería ir al núcleo de tu producto.
Esta factura no llega el primer día. Usualmente aparece años después. Para entonces, puedes verla: esa página de login que escribiste era ya infraestructura de identidad que correría durante toda la vida útil del producto.
La autenticación probablemente no es tu negocio principal. Cuanto antes lo aceptes, antes puedes invertir tu tiempo, energía y recursos en el producto que realmente estás construyendo.
¿Deberías nunca construir tu propio sistema de autenticación?#
No. Demos tempranas, herramientas internas, pruebas de concepto o necesidades de autorización muy específicas que las opciones comerciales no resuelven pueden justificarlo. Lo que debes evitar es asumir a largo plazo una pieza genérica de infraestructura de identidad sin darte cuenta y dejarla bajo el mantenimiento de un equipo de negocio.
¿Cuál es la diferencia entre autenticación y autorización?#
La autenticación responde "¿quién eres?". La autorización responde "¿qué puedes hacer?". En un SaaS real ambas son difíciles de separar: usuarios, organizaciones, roles, permisos, sesiones, claims de token y logs de auditoría están entrelazados. Así que cuando cambias tu sistema de autenticación, no puedes mirar sólo la página de login.
¿Por qué el SSO empresarial complica la autenticación casera?#
Porque significa conectar tu producto con el sistema de identidad del cliente. Diferentes clientes usan diferentes IdPs, protocolos, campos, certificados y modelos de organizaciones. Hacer funcionar el primero no significa que el resto sea copiar-pegar. A menudo es trabajo casi artesanal que solo un ingeniero entiende.
Llevamos años manteniendo el nuestro. ¿Podemos migrar aún?#
Sí, aunque un corte radical rara vez es el camino. Migra por capas: redirige nuevos registros, inicios de sesión y SSO empresarial primero a la nueva plataforma de identidad, y migra a los usuarios existentes en su próximo inicio de sesión. Mantén siempre una vía de retroceso y logs de auditoría, así la migración nunca será irreversible.
