Cómo resolver problemas de cookies seguras en proyectos SaaS con múltiples dominios
I have worked as a frontend and backend developer handling technologies such as Django, Ionic, Laravel, MySQL, Spring (Java), Oracle, NodeJS, Angular, VueJS with the goal of developing websites and mobile applications that offer high performance and are interactive.
You can learn more about me by visiting my website: www.stalinmaza.com
#frontend #backend #fullstack #javascript #nodejs #php
En el desarrollo de aplicaciones SaaS multi-tenant, es común enfrentarse a problemas relacionados con el manejo de cookies seguras cuando los portales de los clientes usan dominios distintos. Esto se debe a que los navegadores modernos aplican políticas muy estrictas de seguridad (SameSite, Secure, HttpOnly, bloqueo de third-party cookies). En este blog quiero compartir un caso real que nos ocurrió y cómo lo solucionamos.
El inconveniente inicial
El proyecto SaaS que manejaba estaba implementado en Kubernetes en Azure, usando cookies seguras para el manejo de sesión. Mientras todos los portales vivían bajo el mismo dominio raíz, no tuvimos inconvenientes.
Ejemplo:
Frontend:
portal_bi.miempresa.comBackend:
api_bi.miempresa.com
Aquí las cookies funcionaban bien porque compartían el mismo dominio (.miempresa.com).
Sin embargo, cuando un nuevo cliente necesitó su propio dominio:
Frontend:
portalcliente_bi.dominioexterno.comBackend:
api_bi.miempresa.dominioexterno.com
El inicio de sesión comenzó a fallar en ciertos casos:
En modo incógnito el inicio de sesión no funcionaba.
A algunos usuarios corporativos, con navegadores más estrictos, también les fallaba.
La causa: el navegador detectaba que las cookies venían de un dominio distinto y las bloqueaba por política de seguridad.
Por ejemplo:
En Brave, el portal funcionaba tanto en el modo incognito y en las ventanas normales, a pesar de que en la consola de desarrollo no se listaban las cookies seguras.
En Edge, Chrome y Firefox, en la ventana normal si aparecían las cookies seguras mientras que en el modo incognito no aparecían y se cerraba la sesión.
Primera hipótesis
Pensamos que tal vez el error estaba ligado únicamente a configuraciones de cookies, así que hicimos pruebas replicando el escenario en un subdominio de pruebas:
Al probar login en ventana normal e incógnito, vimos que en incógnito también se bloqueaban las cookies si el backend estaba en un dominio distinto. Confirmamos que el problema no era de configuración de cookies, sino de cross-domain.
Solución planteada
La solución que adoptamos fue dejar de usar una URL estática de backend y, en su lugar, hacer que el frontend siempre invoque a la API relativa al mismo dominio donde está desplegado el cliente.
Antes:
// Llamada "quemada"
fetch("https://miportal.com/api/v2/endpoint")
Después:
// Llamada relativa al dominio actual
fetch("/api/v2/endpoint")
De esta manera, si el cliente está en:
portalcliente.com, la llamada va aportalcliente.com/api/v2.clientepruebas.dominio-test.com, la llamada va aclientepruebas.dominio-test.com/api/v2.
Y en Kubernetes configuramos el Ingress para que todas las llamadas a /api/v2 se redirijan internamente al servicio backend.
Ventajas de este enfoque
Misma política de dominio: al hacer las llamadas desde el mismo dominio donde está montado el frontend, las cookies seguras se comportan como first-party, no third-party.
Evita bloqueos de navegadores: ya no dependemos de excepciones de Chrome, Edge, Safari o configuraciones corporativas.
Escalable para múltiples clientes: cada dominio de cliente puede usar
/api/v2sin necesidad de cambiar la configuración del backend.Más limpio en Kubernetes: el Ingress enruta todas las peticiones
/api/v2al servicio backend sin importar desde qué dominio se accede.
Conclusión
Si estás desarrollando un SaaS multi-tenant y manejas sesiones con cookies seguras, debes considerar que los navegadores no permiten compartir cookies entre dominios distintos. Esto puede romper el inicio de sesión en incógnito o en entornos corporativos.
Para resolverlo, una estrategia eficaz es:
Evitar URLs absolutas en el frontend.
Usar rutas relativas (
/api/...).Configurar el Ingress de Kubernetes para enrutar esas rutas al backend.
De esta manera, cada cliente accede a tu SaaS con su propio dominio y las cookies seguras funcionan sin restricciones.
¿Te pasó algo parecido en tu proyecto SaaS? 🚀 Déjame tus comentarios y qué soluciones aplicaste para manejar cookies y sesiones en entornos multi-dominio.

