Los problemas de autenticación JWT en prototipos suelen parecer aleatorios. Aprende soluciones para expiración, rotación de refresh, desfase de reloj y patrones seguros de almacenamiento de tokens.
exp), emitido en (iat), desfase de reloj, tokens de acceso de corta vida\n- Almacenamiento: token faltante, sobrescrito, borrado o atrapado en el lugar equivocado\n- Validación: secreto/clave pública incorrecta, aud/iss equivocados, token revocado o rotado\n\nAntes de cambiar código, captura lo básico. Te ahorrará horas de adivinanzas.\n\n- La respuesta exacta que falla (estado + mensaje) y en qué endpoint ocurrió\n- Una marca temporal del cliente y del servidor para la misma petición\n- La hora y zona horaria del dispositivo (especialmente en móvil)\n- Los claims del token (exp, iat, iss, aud) y cuándo se emitió\n\nEjemplo concreto: un fundador prueba en su Mac y todo funciona. Un usuario en Windows sigue desconectándose cada 10-15 minutos. El problema real no es “cierres de sesión aleatorios”: el reloj del usuario tiene 6 minutos de retraso, el access token expira rápido y el servidor lo rechaza sin tolerancia. Abre una segunda pestaña y también puedes conseguir que una pestaña refresque y la otra sobrescriba los tokens almacenados.\n\nSi tu prototipo fue generado por herramientas como Lovable, Bolt o Cursor, es común ver un manejo inconsistente de tokens entre páginas. FixMyMess suele encontrar una mezcla de expiraciones cortas, lógica de refresh ausente y almacenamiento inseguro ocurriendo a la vez.\n\n## Fundamentos de JWT que necesitas para depurar (sin el volcado teórico)\n\nUn JWT es solo una nota firmada. Tu servidor la firma para poder verificar después que el token fue emitido por ti y no fue alterado. La mayoría de JWT no están cifrados, así que cualquiera que tenga el token puede decodificarlo y leer su contenido.\n\nEso conduce a la primera regla práctica: trata los JWT como identificaciones legibles, no como bóvedas secretas. Si un token se filtra (logs, almacenamiento del navegador, capturas de pantalla, herramientas de analítica), lo que hay dentro también se filtra.\n\n### Los pocos claims que explican la mayoría de fallos\n\nCuando los tokens “dejan de funcionar aleatoriamente”, normalmente es uno de estos campos o cómo tu app los comprueba:\n\n- exp (expires at): el momento en que el token debe rechazarse.\n- iat (issued at): cuándo se creó el token. Útil para depurar problemas de tiempo.\n- nbf (not before): el token debe rechazarse hasta esa hora.\n- aud (audience): para quién está pensado el token (una API específica).\n- iss (issuer): qué sistema emitió el token.\n- sub (subject): el usuario o entidad que representa el token.\n\nUn desajuste común en prototipos: el frontend envía un token a la API B que fue emitido para la API A (aud incorrecto), o el backend es estricto con iss en un entorno pero no en otro.\n\n### “Falla” puede significar dos cosas opuestas\n\nLos problemas de auth con JWT a menudo provienen de validaciones ausentes o excesivamente estrictas.\n\nSi faltan comprobaciones, los tokens podrían funcionar cuando no deberían (hueco de seguridad), y luego “de repente fallan” cuando añades una regla de validación.\n\nSi las comprobaciones son demasiado estrictas, los usuarios son desconectados por diferencias mínimas, como un servidor 60 segundos adelantado (más sobre el desfase de reloj más adelante), o un token válido que no coincide exactamente con la cadena esperada en aud/iss.\n\n### Qué nunca debe ir en un JWT\n\nNo pongas secretos o datos sensibles en la carga útil de un JWT: contraseñas, claves de API, credenciales de base de datos, códigos de restablecimiento o datos personales que no quieras que acaben en una hoja de cálculo. Mantenlo mínimo: un ID (sub), quizá un rol o algunos permisos, y los claims temporales.\n\nSi heredas un prototipo generado por IA, esto es un problema frecuente que vemos en FixMyMess: tokens que incluyen por accidente claves internas o demasiados datos de usuario, y luego se almacenan en lugares inseguros. Incluso si la autenticación “funciona”, está a un paso de convertirse en un incidente real.\n\n## Problemas de expiración: ajustes de exp y iat que causan cierres sorpresa\n\nLa mayoría de problemas de autenticación JWT en prototipos no son “aleatorios”. Suelen ser cálculos de expiración que parecen correctos en pruebas locales y luego se rompen cuando aparecen dispositivos reales, redes reales y diferencias temporales reales.\n\nUnos pocos errores provocan la mayoría de cierres sorpresa:\n\n- exp demasiado corto. Cinco minutos suena seguro, pero es brutal para prototipos con cold starts lentos, apps móviles en segundo plano y conexiones intermitentes. Los usuarios vuelven tras una breve pausa y todas las llamadas fallan.\n- exp ausente. Algunas librerías aceptan tokens sin expiración, otras no, y tu propio código puede tratarlos como expirados. Esto crea comportamientos confusos e inconsistentes entre entornos.\n- iat en el futuro. Ocurre cuando el reloj del servidor está mal, usas la zona horaria equivocada, o generas tokens en un servicio y los validas en otro. Muchos validadores rechazan tokens “aún no válidos”.\n\nUn patrón por defecto práctico es: token de acceso de corta duración + refresh token de larga duración. Mantén el access token lo bastante corto para limitar el daño si se roba, pero lo bastante largo para sobrevivir al uso normal. Para muchos prototipos, un buen punto de partida son 10 a 20 minutos para el acceso, y días para el refresh. Luego puedes endurecerlo.\n\nEl comportamiento del cliente importa tanto como los ajustes del token. Una buena regla es: manejar un 401 una sola vez.\n\n1) Si una petición devuelve 401, llama al endpoint de refresh.\n2) Si el refresh tiene éxito, reintenta la petición original una vez.\n3) Si el reintento falla o el refresh falla, cierra la sesión y muestra un mensaje claro.\n\nEsto evita bucles de reintento infinitos y pantallas que “se quedan girando”.\n\nEn el servidor, evita errores 500 vagos cuando un token está expirado. Devuelve un 401 claro para tokens de acceso expirados o inválidos, y un 401 (o 403, si prefieres) claro cuando el refresh token es inválido o revocado. Así queda claro si tienes un problema de expiración o un fallo real en el backend.\n\nEjemplo: un fundador prueba en su portátil y todo funciona. Usuarios móviles abren la app después de comer, el access token expiró y la app sigue llamando a la API con el token viejo hasta que abandona. Con el patrón de refresco y reintento una sola vez, ese usuario simplemente continúa sin darse cuenta.\n\nSi heredaste un flujo de auth generado por IA donde los tokens “a veces” fallan, FixMyMess suele encontrar en la primera auditoría una mezcla de exp demasiado corto, validación inconsistente y lógica de refresh ausente.\n\n## Desfase de reloj: cuando tokens correctos fallan porque la hora está mal\n\nAlgunos problemas de auth con JWT no son causados por código defectuoso o “tokens inválidos”. El token puede ser correcto, firmado y no modificado, y aun así fallar porque el reloj del dispositivo o del servidor está mal.\n\nEl desfase de reloj ocurre más a menudo en prototipos de lo que se espera: un teléfono con la hora manual, una VM con drift, un contenedor con una fuente de tiempo mal configurada, o dos servidores en la misma app que discrepan por un minuto.\n\nCuando la hora está mal, normalmente ves fallos alrededor de claims temporales:\n\n- nbf (not before): el servidor cree que el token aún no es válido\n- exp (expires): el servidor cree que el token ya expiró\n- iat (issued at): algunas librerías lo usan para comprobaciones extra y pueden rechazar tokens “futuros”\n\nUn escenario común: firmas un token en el Servidor A, pero la petición del usuario se valida en el Servidor B cuyo reloj va 45 segundos adelantado. De pronto los usuarios se desconectan “aleatoriamente”, o el login funciona y luego falla al cargar otra página.\n\n### Solución práctica: añade una pequeña tolerancia al validar\n\nLa mayoría de librerías JWT permiten permitir una pequeña tolerancia al comprobar exp y nbf. Un buen punto de partida es 30 a 120 segundos. Mantenlo pequeño: la leeway sirve para manejar drift, no para alargar sesiones.\n\nSi usas leeway, trátalo como un salvavidas, no como una tirita. Si necesitas 10 minutos de tolerancia, probablemente tienes un problema de sincronización horaria o de despliegue.\n\n### Solución operativa: haz que la hora sea consistente en todas partes\n\nLa leeway reduce fallos falsos, pero aún deberías arreglar la causa raíz. Comprobaciones rápidas que detectan la mayoría de problemas:\n\n- Asegura que todos los servidores y agentes de build sincronicen con la misma fuente de tiempo (NTP)\n- Evita mezclar hosts con hora correcta y contenedores con tiempo aislado o mal configurado\n- Verifica que los dispositivos móviles de prueba tengan la hora automática activada\n- En setups multi-servidor, confirma que las peticiones no reboten entre nodos con tiempos diferentes\n\nSi estás heredando un prototipo generado por IA (común con Lovable, Bolt, v0, Cursor o Replit), los bugs de desfase de reloj pueden quedar enmascarados por el “funciona en mi máquina”. Cuando FixMyMessAudita fallos de auth, a menudo encontramos que una pequeña tolerancia más una sincronización de tiempo adecuada elimina los cierres de sesión intermitentes sin cambiar todo el diseño de autenticación.\n\n## Refresh tokens: la pieza que falta en la mayoría de flujos de prototipos\n\nLa mayoría de problemas de JWT en prototipos ocurren porque la app intenta usar un token para todo: un token de acceso de corta duración que además tiene que mantener al usuario conectado durante días. Esa tensión es por qué las sesiones se sienten aleatorias. Un refresh token existe para mantener la sesión viva sin hacer el access token de larga duración (lo cual es riesgoso si se filtra).\n\nLos access tokens deberían ser aburridos: expiración corta, enviados a menudo, fáciles de reemplazar. Los refresh tokens deberían usarse raramente: únicamente para obtener un nuevo access token, y mantenerse fuera de lugares donde JavaScript o los logs puedan recogerlos fácilmente.\n\nUn error común en prototipos es almacenar el refresh token de la misma manera que el access token (por ejemplo, en localStorage) y tratarlo como una credencial API normal. Cuando ese token se filtra, un atacante puede crear nuevos access tokens hasta que lo notes. Otro error es no tener refresh token en absoluto, así que la app “soluciona” los cierres de sesión poniendo la expiración del access token enorme. Eso suele convertirse en deuda de seguridad más adelante.\n\nAntes de construir el flujo, decide qué debe significar “sesión” para tu producto:\n\n- ¿Cuánto tiempo debe permanecer un usuario conectado sin abrir la app?\n- ¿Cerrar el navegador debe desconectar al usuario o no?\n- ¿Quieres una sesión por dispositivo, o iniciar sesión en uno debe expulsar a otro?\n- ¿Qué sucede después de un cambio de contraseña: cerrar sesión en todas partes, o solo en nuevas sesiones?\n\nEl uso real añade casos límite que los prototipos raramente manejan. Los usuarios abren múltiples pestañas, las redes caen a mitad de petición y dos peticiones pueden intentar refrescar al mismo tiempo. Si no controlas eso, obtienes bucles (refresh, fallo, reintento) o 401s repentinos que parecen “problemas de auth JWT” incluso cuando tus tokens están bien.\n\nSi heredaste un prototipo generado por IA (Lovable, Bolt, v0, Cursor, Replit), esta capa de refresh suele faltar o estar a medio implementar. Arreglarla normalmente quita primero los bugs de “funcionaba ayer” en el login.\n\n## Paso a paso: un flujo de refresh que funciona con rotación\n\nLa mayoría de problemas JWT aparecen cuando los access tokens expiran y la app no tiene una forma fiable de recuperarse. Un flujo de refresh con rotación arregla eso haciendo que la expiración sea normal, no aterradora.\n\n### El flujo (login → refresh → reintento)\n\nEmpieza emitiendo dos tokens al iniciar sesión: un access token de corta duración (minutos) y un refresh token de larga duración (días o semanas). El access token es lo que tu API comprueba en cada petición. El refresh token se usa solo para obtener un nuevo access token.\n\nUna secuencia simple y fiable se ve así:\n\n- El login devuelve access token + refresh token\n- El cliente llama a las APIs con el access token hasta que falla con 401\n- El cliente llama al endpoint de refresh con el refresh token\n- El servidor devuelve un nuevo access token y un nuevo refresh token\n- El cliente reintenta la llamada API original una vez\n\nLa rotación es el detalle clave: cada refresh produce un refresh token completamente nuevo y el viejo deja de ser válido. Así, si un refresh token se filtra, deja de funcionar tan pronto como el usuario real hace un refresh.\n\n### Reglas de rotación que debes implementar del lado servidor\n\nPara que la rotación de refresh tokens sea realmente segura (y no rompa a los usuarios aleatoriamente), mantén estas reglas estrictas:\n\n- Almacena los refresh tokens del lado servidor (hashados), con id de usuario, expiración y un id único de token.\n- En el refresh, acepta solo el id de token actual, márcalo inmediatamente como usado/revocado y emite un nuevo id de token.\n- Si se presenta un token antiguo de nuevo, trátalo como sospechoso y revoca toda la sesión (o exige re-login).\n\nLa concurrencia es donde los prototipos suelen fallar. Dos pestañas, un doble clic o un reintento de la app pueden disparar dos refresh al mismo tiempo. Una estrategia de gracia pequeña evita cierres sorpresa: permite que el refresh token previamente válido se use una vez más en una ventana corta (por ejemplo 10-30 segundos) si acaba de rotarse, pero solo si puedes detectar que pertenece a la misma cadena de sesión.\n\nSi estás peleando con problemas JWT que se sienten aleatorios, normalmente es porque la rotación, el almacenamiento o la concurrencia están a medio implementar. Los equipos suelen traer a FixMyMess un prototipo de Lovable/Bolt/v0/Cursor/Replit donde el refresh parece “hecho” pero falla bajo uso real, y lo endurecemos hasta un flujo apto para producción rápido.\n\n## Patrones seguros de almacenamiento de tokens (web y móvil)\nSi ves problemas de auth JWT que solo aparecen fuera de tu propio navegador, el almacenamiento suele ser la causa. Un prototipo puede sentirse bien en pruebas y luego empezar a desconectar gente cuando añades páginas reales, scripts de terceros o dispositivos distintos.\n\n### Web: trata el refresh token como una contraseña\nPara apps web, la opción más segura por defecto es almacenar el refresh token en una cookie httpOnly y Secure. httpOnly evita que JavaScript la lea (muy útil si alguna vez tienes un bug XSS). Secure asegura que solo viaje por HTTPS.\n\nLas banderas de cookie no son "configurar y olvidar". Hazlas una elección deliberada:\n- httpOnly + Secure: buena base para refresh tokens.\n- SameSite=Lax: suele funcionar para la navegación normal y reduce el riesgo CSRF.\n- SameSite=None: necesario para setups cross-site (dominios diferentes), pero requiere Secure y aumenta la exposición CSRF.\n- Protección CSRF: si el endpoint de refresh es cookie-based, añade defensas CSRF (por ejemplo, un header con token CSRF o una estrategia de doble envío).\n\nEvita almacenar tokens de larga duración en localStorage o sessionStorage. Es cómodo, pero si cualquier script en la página puede ejecutarse (XSS, dependencia comprometida, extensión maliciosa), puede leer los tokens y enviarlos.\n\nLos access tokens son distintos: mantenlos de corta duración y en memoria cuando sea posible. Si un refresco de página los pierde, está bien porque la cookie de refresh puede emitir uno nuevo.\n\n### Móvil: usa almacenamiento seguro, mantén acceso corto\nEn iOS y Android, guarda los refresh tokens en el almacenamiento seguro de la plataforma (Keychain en iOS, Keystore en Android). No pongas refresh tokens en almacenamiento plano de la app ni en logs.\n\nUn patrón práctico:\n- Refresh token: almacenamiento seguro, larga duración, rotado.\n- Access token: sólo en memoria, expiración corta, reemplazado con frecuencia.\n- Al fondo/cerrar la app: descarta el access token y solicita uno nuevo al reanudar.\n\nUna fuente silenciosa de fallos “aleatorios”: tokens filtrados a lugares inesperados. Nunca pongas access tokens en URLs (query params) y límpialos de logs, eventos de analítica, informes de fallos y popups de error. Por ejemplo, si tu app registra la petición completa cuando una API falla, puede capturar accidentalmente la cabecera Authorization.\n\nSi heredaste un flujo de auth generado por IA que mezcla cookies, localStorage y access tokens de larga vida, FixMyMess puede auditarlo rápido y señalar los puntos exactos de fuga y las decisiones de almacenamiento inseguro antes de lanzar.\n\n## Trampas comunes de prototipos que hacen la auth inestable\n\nLos bugs JWT en prototipos suelen sentirse aleatorios porque el sistema está a medias entre estricto y laxo. “Funciona en mi máquina”, luego falla tras un redeploy, añadir un segundo servicio o cuando un usuario abre otra pestaña.\n\n### Trampa 1: Omitir comprobaciones de issuer (iss) y audience (aud)\n\nMuchos prototipos solo validan la firma y la expiración. Puede estar bien para un backend único, pero se vuelve frágil cuando añades una segunda API, un worker en background o un servicio de admin separado.\n\nSi no validas iss y aud, puedes acabar aceptando tokens pensados para otro servicio, y luego “endurecer la seguridad” y de repente usuarios reales reciben 401s porque los tokens existentes no coinciden con las nuevas reglas.\n\nUna forma sencilla de evitar sorpresas es decidir pronto:\n\n- Una cadena issuer para tu servicio de auth\n- Una audiencia por API (o una audiencia compartida si realmente tienes una sola API)\n- Configuraciones consistentes en dev, staging y prod\n\n### Trampa 2: Secretos JWT cambiando entre ambientes o redeploys\n\nLos prototipos suelen generar secretos al arrancar, usar distintos .env por máquina o rotar claves accidentalmente al desplegar. El resultado parece “tokens que dejan de funcionar aleatoriamente”, pero el problema real es que el servidor ya no puede verificar tokens que emitió antes.\n\nSi necesitas redeploys frecuentes, trata las claves de firma como la contraseña de la base de datos: mantenlas estables y gestionadas. Si vas a rotar claves, hazlo deliberadamente (por ejemplo, soportando la clave actual y la anterior durante un solapamiento corto).\n\n### Trampa 3: Confiar en la decodificación cliente en vez de la verificación servidor\n\nDecodificar un JWT en el navegador (o app móvil) no es lo mismo que verificarlo. Un prototipo puede leer la carga útil, asumir que el usuario está logueado y saltarse una comprobación real al servidor hasta más tarde.\n\nEso crea estados confusos: la UI dice “logueado”, pero la API rechaza las peticiones. Haz que el servidor sea la fuente de la verdad y que el cliente trate el “API dice 401” como la señal real para refrescar o reautenticar.\n\n### Trampa 4: Caché incorrecto del estado de auth (especialmente entre pestañas)\n\nUn bug común: una pestaña refresca tokens, otra pestaña sigue usando un access token antiguo y tu app cambia entre funcionar y fallar. Otra variante: cacheas un “usuario actual” en memoria y nunca lo actualizas tras un refresh.\n\nSi tu app corre en múltiples pestañas, decide cómo se propagan las actualizaciones de estado de auth. Como mínimo, maneja eventos de “token actualizado” y “desconectado” limpiamente para no seguir enviando tokens obsoletos.\n\n### Trampa 5: Enviar atajos de auth para depuración\n\nEl código de prototipo a veces acepta tokens sin firmar, usa el algoritmo none o salta la verificación para pruebas. Si algo de eso llega a producción, obtienes tanto riesgo de seguridad como fallos extraños cuando distintas partes del sistema discrepan sobre qué es válido.\n\nSi heredaste un prototipo generado por IA y la auth se siente inestable, FixMyMess puede auditar el código rápidamente (incluida la verificación de tokens, la lógica de rotación y el almacenamiento) y señalar exactamente cuáles de estas trampas estás pisando antes de que los usuarios lo noten.\n\n## Ejemplo: funciona para ti, pero los usuarios se desconectan\n\nUna historia común: pruebas la app todo el día en tu portátil y la auth parece estable. Entregas un preview a usuarios reales y de repente recibes mensajes como “me desconecta cada 10 minutos” o “el login funciona una vez y luego se para”.\n\nAquí tienes un escenario realista. Un fundador construye un prototipo con una herramienta IA, lo ejecuta local y entra con la misma pestaña del navegador. En producción, los usuarios abren la app en el móvil, cambian de red, dejan la pestaña en segundo plano y vuelven más tarde. Ahí es exactamente donde aparecen los problemas JWT: expiraciones cortas, diferencias de reloj y lógica de refresh que solo funciona en el camino feliz.\n\n### Cómo reproducirlo (sin adivinar)\nConvierte los “cierres de sesión aleatorios” en una línea temporal. Pide a un usuario afectado la hora en que inició sesión y la hora en que se desconectó (su zona horaria importa). Luego recoge una petición fallida en el servidor (o en logs) y captura:\n\n- Hora del servidor cuando la petición fue rechazada (401)\n- Los valores exp e iat del token (decodificados en el servidor)\n- Si hubo un intento de refresh y si falló\n- Si el usuario tenía múltiples dispositivos o pestañas abiertas\n\nSi puedes, compara el reloj del servidor con una fuente confiable y con tu máquina local. Unos pocos minutos de drift son suficientes para romper validaciones estrictas.\n\n### Las causas más probables\nEn prototipos, estos problemas reaparecen una y otra vez:\n\n- exp demasiado corto (como 5-15 minutos) y sin flujo de refresh fiable, por lo que los usuarios reciben cierres sorpresa.\n- Fallos por desfase de reloj: el backend comprueba exp e iat sin tolerancia y una máquina tiene la hora ligeramente distinta.\n- Errores en la rotación del refresh token: rotas refresh tokens pero no manejas correctamente el "reuso" del token, o sobrescribes el refresh almacenado en una carrera entre dos peticiones.\n\n### Ruta de corrección práctica\nLas soluciones suelen ser directas si las atacas en orden.\n\nPrimero, añade una pequeña leeway al validar claims temporales (normalmente 30-120 segundos). Eso solo puede parar expiraciones falsas causadas por desfase de reloj.\n\nLuego, haz el refresh fiable. Cuando un access token expira, realiza un único reintento de refresh y luego reenvía la petición original. Si múltiples peticiones alcanzan la expiración al mismo tiempo, asegúrate de que solo una haga el refresh y las demás esperen.\n\nFinalmente, mejora el almacenamiento. Usa cookies seguras para refresh en web cuando sea posible (httpOnly, Secure, SameSite configurado correctamente), y evita tener refresh tokens largos en localStorage. En móvil, usa el almacenamiento seguro de la plataforma.\n\nSi tu prototipo fue generado rápido y la auth es inestable, FixMyMess puede ejecutar una auditoría de código gratuita para señalar dónde la lógica de refresh, la rotación o los patrones de almacenamiento están fallando en uso real, y luego parchearlo para que quede listo para producción.\n\n## Lista rápida y siguientes pasos\n\nCuando los problemas de auth JWT parecen “aleatorios”, normalmente no lo son. Un token falla por un conjunto reducido de razones: los números dentro están mal, el reloj del servidor está desincronizado, el flujo de refresh está incompleto, o tu app almacena tokens de forma frágil.\n\nEmpieza con pruebas rápidas, no con conjeturas. Copia un token fallido, decodifícalo y anota exp, iat, iss, aud y el id/subject. Luego compáralo con lo que tu API valida en ese entorno.\n\nAquí tienes una lista corta que atrapa la mayoría de problemas de prototipo:\n\n- Decodifica un token que falla y confirma que exp está en el futuro y que iat no está “en el futuro” respecto al tiempo del servidor API.\n- Verifica la hora del API: comprueba el reloj del servidor, el tiempo del contenedor y la sincronización del hosting. Incluso unos minutos de drift pueden causar fallos repentinos.\n- Confirma la configuración de firma: asegúrate de que el secreto/clave privada es la correcta para este entorno (dev vs preview vs prod), y que no estás mezclando claves entre servicios.\n- Valida audience/issuer: aud e iss deben coincidir con lo que la API espera en cada entorno (especialmente en despliegues preview).\n- Prueba el comportamiento de refresh: el endpoint de refresh devuelve un nuevo access token de forma fiable, y la rotación no invalida accidentalmente a usuarios con sesión activa.\n\nDespués de eso, haz una prueba de extremo a extremo como un usuario real: inicia sesión, espera a que el access token expire, luego haz una llamada API y observa si la app refresca y reintenta. Si falla, busca estos patrones: refresh token no enviado (flags de cookie mal), refresh token sobrescrito durante rotación, o el cliente que nunca reintenta la petición original.\n\nEl almacenamiento es tu última comprobación rápida: evita poner refresh tokens en localStorage. Para apps web, una cookie HTTP-only es normalmente la opción más segura por defecto. Para móvil, usa el almacenamiento seguro de la plataforma.\n\nSi tu prototipo generado por IA (Lovable, Bolt, v0, Cursor, Replit) tiene auth inestable y necesitas ponerlo en producción rápido, FixMyMess puede realizar una auditoría de código gratuita para identificar qué falla y luego reparar o reconstruir el flujo de forma segura.