# Cómo resolver problemas de cookies seguras en proyectos SaaS con múltiples dominios

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.com`](http://portal.miempresa.com)
    
* Backend: [`api_bi.miempresa.com`](http://api.miempresa.com)
    

Aquí las cookies funcionaban bien porque compartían el mismo dominio (`.`[`miempresa.com`](http://miempresa.com)).

Sin embargo, cuando un nuevo cliente necesitó su propio dominio:

* Frontend: [`portalcliente_bi.dominioexterno.com`](http://portalcliente.com)
    
* Backend: [`api_bi.miempresa.dominioexterno.com`](http://api.miempresa.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**:

* [`clientepruebas.dominio-test.com`](http://clientepruebas.dominio-test.com)
    

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:

```javascript
// Llamada "quemada"
fetch("https://miportal.com/api/v2/endpoint")
```

Después:

```javascript
// Llamada relativa al dominio actual
fetch("/api/v2/endpoint")
```

De esta manera, si el cliente está en:

* [`portalcliente.com`](http://portalcliente.com), la llamada va a [`portalcliente.com/api/v2`](http://portalcliente.com/api/v2).
    
* [`clientepruebas.dominio-test.com`](http://clientepruebas.dominio-test.com), la llamada va a [`clientepruebas.dominio-test.com/api/v2`](http://clientepruebas.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

1. **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.
    
2. **Evita bloqueos de navegadores**: ya no dependemos de excepciones de Chrome, Edge, Safari o configuraciones corporativas.
    
3. **Escalable para múltiples clientes**: cada dominio de cliente puede usar `/api/v2` sin necesidad de cambiar la configuración del backend.
    
4. **Más limpio en Kubernetes**: el Ingress enruta todas las peticiones `/api/v2` al 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.