Fallos de inicio de sesión generados por IA en producción: un flujo de solución de problemas

Cómo son los errores de inicio de sesión que “funcionan localmente"

Un inicio de sesión puede parecer correcto en producción y aún así estar roto. El formulario se envía, ves una respuesta de “éxito” y luego vuelves a la pantalla de login.

Síntomas comunes incluyen:

• Un bucle de redirección entre la página de login y la app
• Pareces “logueado” en una página y de repente estás desconectado
• Obtienes un 401 o 403 después de un refresco aunque haya funcionado hace un momento
• OAuth se completa, pero la app sigue comportándose como si estuvieras desconectado
• Funciona en un navegador o dispositivo y falla en otro

La razón suele ser aburrida: la autenticación depende de pequeños detalles del entorno que cambian entre local y producción. El desarrollo local tiende a ser un solo host, sin proxy, cookies simples y HTTP. Producción añade HTTPS, dominios reales, proxies inversos y a veces un dominio de API separado. Esas diferencias afectan cómo se almacenan las cookies, qué cabeceras recibe el servidor y a dónde apuntan las redirecciones.

Un ejemplo típico: en local inicias sesión y se crea una cookie de sesión que se guarda. En producción, el servidor sigue enviando la cookie, pero el navegador se niega a guardarla porque las banderas de la cookie no coinciden con la configuración real (a menudo SameSite y Secure). El backend piensa que estás logueado, pero el navegador nunca envía esa cookie de vuelta. Desde fuera parece cierres de sesión aleatorios o un bucle infinito de redirección.

No adivines ni reescribas todo tu sistema de auth. Encuentra el paso exacto donde el flujo deja de ser verdadero:

• ¿El servidor envió una cookie o token?
• ¿El navegador la almacenó?
• ¿La siguiente petición la incluyó?
• ¿La redirección aterrizó en el dominio correcto?
• ¿La API aceptó la sesión o el token?

La mayoría de los fallos de auth en producción son comportamiento de configuración y cookies, no el formulario de login.

Equipos como FixMyMess ven esto mucho en prototipos construidos por IA: la UI parece terminada, pero no se trataron con cuidado las reglas de dominios, HTTPS y sesiones para producción.

Antes de tocar el código: recopila un repro limpio

Las victorias más rápidas suelen venir de un repro limpio y repetible, no de adivinar. Si puedes reproducir el bug a demanda, puedes demostrar la solución rápidamente.

Anota el escenario exacto para que otra persona pueda seguirlo sin idas y venidas. Incluye dispositivo (desktop o móvil), nombre y versión del navegador, la página exacta en la que empezaste y qué cuenta de usuario usaste. Si sólo falla en incógnito, con datos móviles o tras tener una pestaña abierta un tiempo, captura eso también.

Aclara también dónde falla. Muchos “bugs de login” no fallan en la pantalla de login. Fallan justo después del login:

• Envías el formulario y rebotas a la página de login
• OAuth parece exitoso, pero el callback nunca concluye
• Entras en la app, pero la primera llamada a la API devuelve 401 y te echan
• Funciona una vez, luego falla tras un refresh o tras 10–30 minutos

Define el éxito en términos concretos. Elige una o dos comprobaciones que usarás cada vez, por ejemplo: existe una cookie de sesión, se guarda un token, o tu endpoint de “current user” devuelve 200. Sin eso, los equipos “arreglan” el estado de la UI mientras el servidor sigue considerando al usuario anónimo.

Añade pistas de tiempo e identidad. Captura una o dos marcas de tiempo cuando reproduzcas el fallo (hasta el minuto). Si tus logs del backend exponen un request ID, session ID o trace ID, regístralo también. Esas migas de pan suelen conectar un síntoma del navegador con el error exacto del servidor.

Una plantilla rápida de repro

Escríbelo como un mini caso de prueba:

• Entorno: producción, navegador + versión, dispositivo
• Pasos: ruta paso a paso desde un estado sin autenticación
• Esperado: tu señal de éxito elegida (cookie establecida, token guardado, “current user” devuelve 200)
• Actual: lo que viste (bucle de redirección, página de error, cierre de sesión repentino)

Un ejemplo realista

Un patrón común es “funciona localmente, falla sólo en el dominio desplegado”. Inicias sesión, ves una breve redirección y luego acabas de nuevo en la página de login.

Tu definición de éxito podría ser: “Después del login, la petición current-user devuelve 200 y la cookie de sesión está presente.” Si reproduces el problema en producción y esa petición devuelve 401, ya has acotado el problema. No es la comprobación de contraseña. Es persistencia de sesión, configuración de cookies, manejo de callback o una incompatibilidad proxy/dominio.

Si heredas un código generado por IA y desordenado, este repro limpio también ayuda a servicios como FixMyMess a diagnosticar más rápido porque señala si la ruptura está en el login, el callback, el refresh o la primera llamada autenticada a la API.

Paso 1: Traza el flujo de login en el navegador

La forma más rápida de dejar de adivinar es observar lo que el navegador realmente envía y recibe. La mayoría de los bugs de auth se muestran claramente en la pestaña Network.

Abre una ventana de incógnito para empezar sin cookies ni cache. Luego abre DevTools y mantén visible el panel Network mientras inicias sesión.

Qué buscar en Network

Encuentra la petición que envía las credenciales (a menudo un endpoint de login o session). Revisa el código de estado, pero no te quedes en “200”. Una respuesta puede ser exitosa y aun así no establecer una sesión o devolver un token usable.

Luego sigue las peticiones siguientes. Si tu flujo usa redirecciones (común en OAuth), haz clic en cada respuesta de redirección e inspecciona la cabecera Location. Muchas fallas en producción se deben a una redirección al dominio equivocado, al path equivocado o a HTTP en lugar de HTTPS.

Una forma rápida de recorrer el flujo:

• Identifica la primera petición de auth y anota el código de estado.
• Para cualquier respuesta con redirección, confirma que Location apunta a donde esperas.
• Inspecciona las cabeceras de respuesta en busca de Set-Cookie.
• Fíjate en advertencias de DevTools sobre cookies bloqueadas.
• Confirma que la siguiente llamada a la API incluya una cabecera Cookie o Authorization.

Confirma que el navegador aceptó la sesión

Si ves Set-Cookie en la respuesta, el navegador aún puede rechazarla. Chrome suele mostrar la razón en los detalles de la cookie o en la pestaña Issues (SameSite, Secure, dominio o path son causas comunes).

Finalmente, revisa la primera llamada autenticada tras el login, como current-user o profile. Mira las cabeceras de la petición. Si no hay Cookie ni token Authorization, el navegador no está llevando la prueba de sesión. Eso acota bien el problema: no es “el backend olvidó quién soy”, es “el cliente no envió la prueba de login”.

Un patrón que ve FixMyMess a menudo: todo funciona en dev local, pero en producción el callback de OAuth completa y la UI sigue mostrando “desconectado”. En Network suele verse el momento en que la cookie se estableció para un host local o fue bloqueada por faltar Secure en un sitio HTTPS.

Paso 2: Arregla las banderas de cookie que rompen sesiones

Las cookies son una causa frecuente de fallos “funciona localmente”. Local es indulgente. Producción no.

Empieza comprobando las cookies inmediatamente tras una respuesta exitosa de login. Buscas la cookie de sesión (o la cookie de refresh) y si se almacena realmente y luego se envía en la siguiente petición.

Las banderas que deciden si tu cookie sobrevive

Domain y Path deciden dónde se envía la cookie. Si tu frontend y API viven en hosts distintos, una cookie con un scope demasiado estrecho puede que nunca se incluya donde esperas. Path también puede fallar: una cookie establecida para un path de auth no se enviará a otras rutas de API.

SameSite es la más importante para OAuth y redirecciones entre sitios. Si el flujo implica salir de tu sitio y volver, la configuración de SameSite puede hacer que la cookie desaparezca entre saltos. En muchos casos de OAuth necesitas SameSite=None, y eso viene con una regla estricta: también debe ser Secure.

Secure indica al navegador que sólo envíe la cookie por HTTPS. Eso es correcto para producción, pero puede romper en entornos de staging u otros que usen HTTP.

HttpOnly impide que JavaScript lea la cookie. Normalmente eso es lo que quieres. Un error común en código generado por IA es que el frontend intenta leer la cookie de sesión desde JavaScript y asume que el login falló cuando no puede hacerlo.

Antes de cambiar código, comprueba estos fallos comunes:

• El dominio de la cookie coincide con el host real de producción (sin valores locales sobrantes)
• El path de la cookie es lo suficientemente amplio (a menudo la raíz /)
• SameSite coincide con tu flujo (especialmente redirecciones OAuth)
• Secure está habilitado en entornos HTTPS
• No tienes cookies duplicadas con el mismo nombre pero scopes distintos

Un ejemplo rápido: un fundador despliega detrás de un proxy inverso, OAuth “tiene éxito”, pero la app vuelve a estado desconectado. DevTools muestra dos cookies con el mismo nombre de sesión, cada una con un scope distinto. El navegador envía la equivocada, así que el servidor la rechaza. Esto suele parecer “auth aleatoria” hasta que inspeccionas el scope de las cookies.

Paso 3: Comprueba HTTPS, dominios y proxies inversos

Si funciona localmente pero falla en producción, el culpable suele estar fuera de tu lógica de auth: HTTPS, el dominio público y cómo se coloca la app detrás de un proxy.

Asegúrate de que la app conoce el protocolo y host reales

Muchas configuraciones de producción ponen la app detrás de un load balancer o proxy inverso. El navegador habla con el proxy por HTTPS, pero tu app puede ver la petición entrante como HTTP a menos que confíe correctamente en forwarded headers.

Cuando eso sucede, los síntomas comunes incluyen cookies establecidas sin Secure, redirecciones a HTTP y fallos de OAuth porque la app construye la URL de callback equivocada.

Comprobaciones rápidas:

• En los logs del servidor, imprime el protocolo y host que la app cree haber recibido.
• Verifica que el proxy envíe forwarded headers (protocol y host son los habituales).
• Asegúrate de que tu app esté configurada para confiar en el proxy y use esas cabeceras de forma segura.

Elimina bucles de redirección y redirecciones al “lugar equivocado”

Un fallo clásico en producción: inicias sesión, entras en la app un momento y luego te vuelven a lanzar a login una y otra vez. A menudo el login tuvo éxito, pero la cadena de redirección alterna entre HTTP y HTTPS o entre dos hosts.

Revisa la pestaña Network para los destinos exactos de redirección. Busca patrones como:

• Bucles HTTP <-> HTTPS
• Redirecciones a un dominio de staging u otro antiguo
• Redirecciones a un puerto local que no existe en producción

También confirma que cada URL relacionada con auth use el dominio público. Los proveedores OAuth son estrictos. Si tu callback registrado es una URL pero tu app envía a otra, fallará.

Subdominios, scope de cookies y bloqueos del navegador

Si usas varios subdominios (por ejemplo, uno para la app y otro para la API), decide si las cookies deben compartirse o aislarse. Las cookies compartidas suelen necesitar un scope de dominio padre; las aisladas deben evitarlo.

Las funciones de privacidad del navegador importan. Si tu login depende de cookies en un contexto de tercero (flujos embebidos, redirecciones cross-site), algunos navegadores las bloquearán a menos que SameSite y Secure estén correctos.

Si quieres una segunda opinión sobre proxies y dominios, FixMyMess suele encontrar la redirección o cabecera exacta que causa la ruptura durante una auditoría de código gratuita.

Paso 4: Depura callbacks y redirecciones de OAuth

Los fallos de OAuth resultan confusos porque el navegador salta entre sitios, y el error puede aparecer en la página del proveedor, en tu ruta de callback o en ningún sitio.

Localiza exactamente dónde falla

Reproduce el login y fíjate dónde aterrizas:

• Si aterrizas en una página de error del proveedor, el proveedor está rechazando tu petición (a menudo mismatch de redirect URI).
• Si rebotas a tu sitio y obtienes un error de la app, tu handler de callback o el intercambio de token está fallando.
• Si vuelves “con éxito” pero sigues viendo la app como desconectada, el callback puede completarse pero la sesión no guardarse.

Comprobaciones de alto impacto:

• Compara el redirect URI configurado con la URL de callback real carácter por carácter (esquema, dominio, path, slash final).
• Confirma que las variables de entorno usadas en este despliegue sean las correctas (client ID, client secret, issuer y base URL de la app).
• Asegúrate de que state (y nonce para OIDC) se genere, almacene y valide tras la redirección.
• Verifica que el callback alcance tu ruta backend y que el código de autorización esté presente.
• Comprueba que el intercambio de código devuelva tokens y que manejes errores en vez de tragártelos.

Patrones comunes de incompatibilidad

Los mismatch de redirect URI rara vez son obvios. Errores típicos incluyen HTTP vs HTTPS, usar un subdominio distinto, mezclar paths de callback o añadir una slash final en un lugar y no en otro.

Los bugs de state y nonce son comunes en código generado por IA. Si la app guarda state en memoria, despliegues serverless o múltiples instancias pueden perderlo entre redirecciones. Si lo guarda en una cookie, esa cookie puede no sobrevivir al bounce entre sitios.

Un ejemplo realista: el login con Google funciona en local, pero en producción devuelve “Invalid state.” La causa suele ser que la configuración de base URL sigue apuntando a local, así la cookie de state se escribe para el host equivocado y nunca regresa en el callback.

Si necesitas una segunda opinión, FixMyMess suele comenzar mapeando la URL de redirect exacta, el almacenamiento de state y la respuesta del intercambio de tokens para que el punto de fallo quede claro rápido.

Paso 5: Valida JWTs y refresh de tokens

Si el login “funciona” pero los usuarios se desconectan tras un refresh, abrir una nueva pestaña o pasados 10–30 minutos, trátalo como un problema de tokens hasta que se demuestre lo contrario. Pequeñas diferencias en tiempo, claves y reglas de validación pueden convertir un token que parece bien en local en uno que falle en todas las peticiones en producción.

Empieza por lo que el servidor piensa del token

Decodifica el token y comprueba su expiración. Luego compárala con la hora actual del servidor. Unos minutos de skew pueden hacer que un token nuevo parezca expirado, lo que se manifiesta como 401 aleatorios.

A continuación, confirma la configuración de firma y validación coincide con producción:

• Algoritmo: servidor y cliente deben estar de acuerdo en el algoritmo de firma.
• Secreto o claves: verifica que el secreto de firma o la clave pública desplegada sean las que el servidor realmente usa.
• Reglas de validación: comprueba issuer y audience. Estos suelen diferir entre local y producción, especialmente si copiaste valores de ejemplo de un fragmento generado por IA.

Un caso común “funciona localmente”: el código local omite las comprobaciones de issuer/audience por comodidad, pero el middleware de producción las impone. El token es válido, pero el servidor lo rechaza por audience incorrecto.

Prueba que el refresh funciona tras comportamiento real del usuario

El refresh de token debe funcionar tras un reload o una nueva pestaña. Prueba una secuencia realista: inicia sesión, cierra la pestaña, vuelve a abrir el sitio y haz una llamada a la API. Si la app guarda el access token sólo en memoria, desaparece al recargar y el usuario parecerá desconectado.

Cuidado dónde guardas tokens. El almacenamiento que sobrevive recargas es cómodo, pero aumenta el riesgo si la página tiene un bug XSS. Las cookies pueden ser más seguras si están bien configuradas, pero también pueden perderse si sus flags o domain están mal.

Si heredaste código de autenticación generado por IA, es común encontrar un flujo de refresh a medio terminar (se emite un refresh token pero nunca se usa, o el cliente nunca guarda el token renovado). El endpoint de login parece correcto, pero el camino “tras refresh” nunca se probó.

Una comprobación rápida: registra en el servidor la razón del rechazo del token (expirado vs firma vs issuer/audience). Sin eso estás adivinando.

Comprobaciones del lado servidor: CORS, CSRF y almacenamiento de sesiones

Las pistas del navegador son sólo la mitad de la historia. El servidor puede estar rechazando peticiones silenciosamente o guardando sesiones en un sitio que tu app no lee de forma fiable.

CORS: permite el origen real (y credenciales)

Los problemas de CORS suelen parecer “inició sesión, pero la siguiente petición es anónima.” En producción normalmente tienes orígenes de frontend y API distintos.

Asegúrate de que tu API permita explícitamente el origen de producción (esquema + dominio) y que esté configurada para aceptar credenciales si usas cookies. Si el frontend envía requests con credentials activado pero la API no devuelve las cabeceras CORS correctas, el navegador puede ignorar la respuesta o desechar cookies.

Una lista rápida del servidor:

• Permite el origen exacto de producción (scheme + dominio)
• Devuelve la cabecera de credenciales cuando uses cookies
• Maneja peticiones preflight (OPTIONS) y devuelve las cabeceras esperadas
• Evita middlewares de CORS conflictivos múltiples
• Confirma que allowed headers incluyan lo que realmente envías (como Authorization)

CSRF: POST funciona localmente, falla en prod

Si el login usa POST (o tienes logout, refresh o actualizaciones de perfil), las reglas CSRF pueden romper sólo en producción. Dos causas comunes son tokens CSRF faltantes y reglas de cookie más estrictas.

Para sesiones basadas en cookies, un SameSite estricto puede impedir que el navegador envíe la cookie en POST cross-site. El servidor entonces rechaza la petición porque parece que falta o es inválido el token CSRF.

Para depurar rápidamente, registra estos campos de la petición que falla: origin de la petición, cookies recibidas, token/header CSRF y la razón de rechazo del framework.

Almacenamiento de sesión, balanceo de carga y secretos

Un fallo clásico solo en producción: inicias sesión, obtienes una sesión y luego cada petición parece un usuario nuevo. Esto suele significar que las sesiones no se comparten entre instancias.

Si ejecutas más de un proceso servidor (o tu host hace auto-scaling), necesitas sticky sessions o un store de sesiones compartido. También confirma que el nombre de la cookie de sesión y cualquier prefijo de claves sean consistentes entre instancias.

Revisa las variables de entorno también. Un secreto de auth, clave de firma o clave de cifrado de sesión faltante puede causar cierres de sesión “aleatorios” tras un deploy porque la app usa un valor por defecto. Si ese valor cambia entre reinicios, las sesiones existentes se vuelven ilegibles.

Si heredaste una app generada por IA y el comportamiento de auth del lado servidor es inconsistente entre entornos, FixMyMess puede usar una auditoría de código gratuita para señalar los problemas de CORS, CSRF, almacenamiento de sesión y secretos antes de que decidas rehacerlo.

Trampas comunes en código de autenticación generado por IA

El código de auth generado por IA suele funcionar en dev local porque todo es simple: un dominio, un puerto, sin proxy y normalmente HTTP. Producción añade HTTPS, dominios reales y a menudo un proxy inverso. Pequeñas suposiciones se convierten en grandes fallos y el navegador te da un vago bucle de redirección.

Un patrón que causa mucho dolor es mezclar estilos de auth sin reglas claras. Por ejemplo, la app establece una cookie de sesión tras login, pero la API también espera un bearer token. Localmente puedes enviar ambos por accidente y “simplemente funciona”. En producción, un camino comprueba la cookie y otro el token, y acabas medio logueado.

Trampas que aparecen una y otra vez

Fíjate en estas señales cuando revises código y configuración:

• Incompatibilidad de entornos: suposiciones locales sobre HTTP, dominios y puertos se filtran a producción.
• Dos fuentes de verdad: existen cookies de sesión y JWTs, sin una regla clara de cuándo usar cada uno.
• URLs hardcodeadas: valores de redirect o callback de OAuth están embebidos en el código, o las base URLs se ensamblan de forma inconsistente.
• Sorpresas por rotación de secretos: redeploys que cambian claves de firma o secretos de sesión, cerrando usuarios o rompiendo refresh.
• Errores tragados: un catch devuelve “ok” o redirige al login, ocultando el 401/403 real o el error de token.

Un ejemplo realista: una app generada por IA hace login bien en local. En producción, los usuarios envían el formulario pero rebotan al login. La causa raíz son tres pequeños problemas juntos: la cookie carece de Secure, el callback de OAuth sigue usando ajustes locales y los errores de token se atrapan y convierten en redirecciones. El navegador sólo muestra redirecciones, así que parece que “auth está rota”, no que “la cookie se cayó”.

Si heredaste un proyecto generado por IA (Lovable, Bolt, v0, Cursor, Replit) y ves estos patrones, FixMyMess suele empezar identificando una sola fuente de verdad para la auth, luego endureciendo secretos y la configuración de entorno para que los logins sobrevivan tráfico real y redeploys.

Una lista de verificación corta, un ejemplo real y próximos pasos

Puedes ahorrar horas comprobando lo básico en el orden correcto. La mayoría de los bugs de auth que “funcionan localmente” no son misteriosos. Normalmente son cookies que no se almacenan, redirecciones al lugar equivocado o la app que no envía credenciales en la primera llamada a la API.

Una lista rápida que puedes ejecutar en 5–10 minutos:

• Tras el login, ¿ves un header Set-Cookie (o una respuesta con token) en el panel Network?
• ¿El navegador guarda realmente la cookie con el dominio, path y expiry esperados, o la rechaza?
• En la siguiente petición, ¿se envía la cookie (o aparece una cabecera Authorization) en la primera llamada autenticada a la API?
• Si usas OAuth, ¿la URL de callback en la configuración del proveedor coincide exactamente con lo que usa tu app en producción?
• Durante el intercambio de código, ¿devuelve el servidor 200, o ves un 400/401 silencioso por secreto incorrecto, redirect malo o problema de proxy?

Un patrón real: OAuth funciona en local, falla en el dominio de producción. Localmente todo completa. En producción, el proveedor redirige de vuelta, pero la app nunca queda “logueada”. En Network suele detectarse: el callback llega a tu servidor, el servidor intenta establecer una cookie de sesión, pero la cookie se bloquea por faltar Secure en HTTPS o porque SameSite es demasiado estricto para una redirección cross-site. La UI carga, llama inmediatamente al endpoint current-user, esa petición no tiene cookie, el servidor devuelve 401 y la app re-bouncea a login.

Si el flujo sigue sin estar claro, asume que el código está enredado, no tú. El código de auth generado por IA a menudo mezcla responsabilidades de cliente y servidor, duplica lógica de sesión u oculta configuración crítica en varios lugares. Una auditoría enfocada suele ser más rápida que adivinar.

FixMyMess (fixmymess.ai) puede diagnosticar y reparar flujos de auth generados por IA, incluyendo cookies, sesiones JWT, callbacks de OAuth y preparación para despliegue. Si quieres una lista clara de lo que está roto antes de comprometerte a cambios, ofrecemos una auditoría de código gratuita y muchas reparaciones se completan en 48–72 horas.