Creo que esta super claro que es un tema que la comunidad necesita , Por favor midu un video/curso sobre este tema y las mejores practicas, no tienes que ser super extenso pero si que nos deje el camino para seguir investigando o algunos referentes
Si a las cookies que tienen tiempo de vida les pasa lo mismo. El tema es que la información que viene dentro de los jwts deberían estar encriptadas o agregarle algunos niveles mas de seguridad.
Si y no. Es casi lo mismo con twitch donde tambien tiene las sesiones de vida util ilimitado. Aun que sí desconosco lo del develop de la estructura de las sesiones en twitch. Aun que para diferentes plataformas que sean. Deberian ser com vida util limitada.
Pero hay algunas apps que renuevan el JWT si es valido y entrega uno completamente nuevo con un nuevo tiempo de expiración. Para mantener la sesión iniciada si esta en constante uso
@@cesar7111pues como todo en la vida, hay pros y contras. Si quieres seguridad pierdes experiencia de usuario. Y si quieres experiencia de usuario, necesitas tener mecanismos que solventen los problemas de seguridad.
Recuerdo haber leído un tweet de Matteo Collina donde decía que le daba miedo la cantidad de brechas de seguridad que podrían existir en un futuro por culpa de “RUclipsrs” o “influencers” que tenían video/cursos donde implementaban sistemas de autenticaciones con vulnerabilidades. Ya veo que tenía razón
muy interesante lo que explicas. me acuerdo que en el curso de node nos quedamos en las cookies (no de terceros) y dijiste que hariamos "sesiones" en la próxima clase. y ya hace no sé cuanto que estoy esperando que sigas el curso y expliques lo de las sessions. molaria un repaso practico de todo esto que has contado, con código usando supabase mismo ya que reexplicar esto puedes evitarte errores muy jodidos como lo que explicas :)
Hace un par de años desarrollando un proveedor de identidad me encontre con problemas similares. Consultando bastante diversas opciones de cara a securizar me encontre con lo que llaman BFF (Backend for Frontend) que basucamente consiste en tener un proxy inverso entre cliente y servidor. Este proxy almacena los JWT y los resfrestokens y al cliente solo le pasan la cookie con un tiempo limitado, aumentando al final la seguridad de no pasarle esa info al cliente. Obviamente tiene sus contras como es tener un mayor delay al tener el rpoxy inverso entre cliente y servidor pero para este tipo de situaciones creo que merece mucho mas la pena, teniendo en cuenta que a dia de hoy manejamos altas velocidades. Otra cosa (aqui ya no recuerdo si funcionaba asi) es la posibilidad de dar de baja los persistence tokens en la bbdd del proveedor de identidad. Flipo que kick tenga este tipo de problemas teniendo en cuenta la cantidad de pasta que tienen que manejar
La expiración del JSON Web Token (access token) debe ser de minutos (unos 5), el refresh token que se usa para renovar el access token debe almacenarse unicamente en una http only cookie de esa manera javascript no puede leerlo ni modificarlo.
Los JWT podrán ser muy buenos siempre y cuando les des un buen uso. Como Backend para mayor seguridad, tengo una Secret General y una Secret a nivel de usuario el cual es un GUID a base de la contraseña (Así si lo reinician, cambia). Los concateno y es la secret del JWT además tienen una expiación dependiente del tipo de software. Además tengo el device_ID qué es una concatenacion de igual manera. Luego al momento de pasar a realizar peticiones. Consulto a la base de datos con el usuario que me llega. Y hago las respectivas validaciones y concatenaciones. Podrá mi aplicación ser unos milisegundos más lenta, pero es más segura. Esto es como el conducir, primero la seguridad y luego la velocidad.
Un JWT con expiración de 1 semana. Fin. Y si ocurre esto, se banea la cuenta original temporalmente hasta que expire. Mucha ingeniería en Kick pero lo más básico no lo hacen.
Banear la cuenta hasta que expire significaría dejar al usuario también sin acceso. Ademas cómo baneas la cuenta si estas usando jwt sin estado ni interacción con la base de datos? 1 semana es un período de expiración demasiado largo si se usa un único jwt y también tiene el problema de información desactualizada (por ejemplo el usuario cambia de mail pero en el jwt sigue teniendo el mail anterior por una semana entera). La solución mas básica es tener token de acceso con 5-10 minutos de expiración y un refresh token que al verificarlo y si está expirado el de acceso, se hace una petición a la base de datos para renovar el token de acceso ( debe estar el secret del refresh token en la base de datos asociado al usuario ). De esa forma si el secret del refresh token es inválido, no se renueva y por lo tanto se cierra la sesión, dandole a un posible hacker como máximo 5-10 minutos de usar la cuenta del usuario. Esto se puede ampliar dandole más funcionalidades como limite de tokens y dispositivos.
en el estandar de JWT hay un campo que se llama JTI (Json Token Identifier) que se puede incluir en los token JWT; este campo, es basicamente pues eso un identificador que te puedes guardar por ejemplo en base de datos en el lado del servidor y seguir una estrategia de lista blanca o lista negra (esto ya a gusto de cada uno y segun sus necesidades) para si existe el JTI en base de datos y el token es valido (esto es si fuera usando la estrategia de lista blanca), considerarlo valido. Aunque tambien es verdad que el utilizar este campo hace que pierda la naturaleza stateless de un token JWT ...
Que opinas de guardar los jwt en la base de datos para validarlo y dado el caso de ser necesario se inválida o elimina de la base de datos y el usuario no podrá ingresar.
Igual me equivoco, pero creo que el problema no está en JWT (que hace lo que tiene que hacer), sino en la (posible) implementación de OAuth (o sucedáneo). Lo que comentas de refrescar, cambiar, banear, etc se hace con el servicio de autenticación (y dependen de cómo esté implementado el servicio y su autorización). Por proponer cosas, sin más. Gracias por tus videos.
Por lo general, mi enfoque consistía en limitar el acceso a múltiples dispositivos, aunque entiendo que esta práctica puede resultar tediosa para el usuario. Implementaba un sistema basado en tokens generados por el navegador. Por ejemplo, si ya existían varias sesiones activas (incluyendo la del JWT), almacenaba información tanto del navegador como del dispositivo desde el cual se accedía. Esto me permitía identificar el origen y momento del ingreso de un usuario y evitar que utilizara sus credenciales de forma indiscriminada en diferentes dispositivos. En caso de que se necesitara finalizar la sesión de un usuario en un dispositivo específico, simplemente eliminaba el token asociado a ese navegador o dispositivo. Esto cerraba automáticamente la sesión, ya que la validación del token estaba vinculada a cada dispositivo. Si el token ya no existía o no estaba activo, el acceso se bloqueaba de forma efectiva.
Me tocó ver como hacíamos el cambio a auth con jwt y con un poco de investigación para montarlo ya podía llegar a ver esos problemas… Al final optamos por tener un jwt que dura minutos (quizás excesivamente corto, pero refrescarlo no cuesta realmente), y un refresh de un solo uso que dure una semana. Si tenemos que cerrar la session de alguien, borramos su refresh en la base de datos y listo. En algún momento para controlar distintos dispositivos que tengan la sesión abierta a la vez pues simplemente tener unos por usuario y dispositivo. Igual es porque planteamos las cosas en modo paranoico, pero no es tan difícil, es triste que empresas grandes no se paren a pensar en el usuario malicioso antes de hacer estas cosas…
Recomendaría refresh tokens o sliding tokens, ya que así de cierta forma siempre se valida con la bd el estado del token y asi evitamos este tipo de cosas
Tengo un proyecto y guardo información del propio usuario en el local storage a modo de caché para ahorrar peticiones a la db cuando no hay cambios, no es información confidencial, pero si privada, la información está cifrada con CryptoJS. Mi pregunta es, qué tan seguro es este método?
No te preocupes lo que pasó con Kick fue por no hacer las cosas bien, lo que si te diría es que investigues que cabeceras viajan en cada petición y cuáles puedes usar para autenticar al usuario (saber si es el en realidad y no un hacker)
bueno pues te recomiendo que los jwt solo deben durar 15 minutos o máximo 30, el que debe de durar aprox 7 días es el refresh token, lo que le paso a KICK fue algo demasiado básico.
En PcComponentes pasa exactamente lo mismo. Un tío tenía mi cuenta abierta, y podía hacer pedidos con mi tarjeta guardada después de cambiar la contraseña y la del correo. No tienen forma de invalidar la sesión, y aun guardando tarjetas de crédito, no tienen MFA. No quedó otra que borrar las tarjetas y olvidar la cuenta, ya no es segura. Ha sido este mes, por cierto.
y si encriptamos el jwt en el lado del cliente? ya no seria factible robarlo desde el local o session storage, ademas si el jwt le ponemos una vida de solo unos minutos y al refresh una mas larga, pero guardandola en bd, eliminandola desde bd podemos mitigar el acceso del jwt y solicitar inicio de sesion nuevo
Si bien es un caso aislado, al conocimiento que jwt podría ser vulnerado existe ya hace rato, empecé a usar paseto por lo mismo, ahora, independientemente de ello, cualquier tecnología será insegura y/o mala si no se implementa bien. Kick se acaba de dar no un disparo si no un escopetazo de PR en el pie.
Recuerdo que Midu hizo un ejemplo en Node con JWT hace mucho tiempo y si mi memoria no me falla, el comento que estaba pendiente el refresh token. Cuando el tenga tiempo, y si le apetece, seria interesante ver como se implementaria el refresh y medidas de seguridad o documentacion para disminuir las fallas que tuvieron en kick
Lo que yo he visto para evitar estos casos es: - tokens de duración corta (unos cuantos minutos), usando un secret "compartido" - + refresh tokens con una duración más larga, usando como secret un hash creado a partir del hash del password del usuario De esta forma, si el password del usuario cambia, el refresh token automáticamente queda inválidado. En este caso, un administrador de kick podría cambiarle el password al usuario hackeado y así invalidaría todos los refresh tokens. Es decir, en cuestión de minutos el token principal vence y es imposible refrescarlo con un refresh token anterior al cambio de password.
Entonces sería un sistema más parecido al SSH. También se podría incluir un payload en el token con la IP o algún dato que identifique el dispositivo. Además de tener una expiración corta.
El usar un secret por usuario solucionaría el tema de no poder desloguearse. Normalmente se toman parte del Id del usuario o en combinación con otro campo unico
Como estándar se debe manejar que la expiración sea de una hora. Además que mal kick al no añadir la opción de cerrar sesión de todos los dispositivos que se registren en la cuenta.
En el proyecto para la empresa en la que trabajo, implemente JWT tokens, pero con sesiones corta 30 minutos de instintiva, sesión única, recuperación de sesión por correo electrónico, 2FA, y verificación del token en base de datos, de además de poder cerrar sesión desde la base de datos, esto último sacrifica velocidad, pero la seguridad es primero y más para un ERP
Los JWT tienen que utilizarse con un mecanismo de "renovación" de los tokens cada 30 minutos. Eso evita que el token generado se pueda reutilizar. El problea es que los token generados no se pueden eliminar del servidor una vez tu te desconcetas o cierras la sesión. Por eso se recomienda primero, poner tiempos de utiliza del token no mayor a 30 minutos y luego cerrar la sesión automáticamente o bien, regenerar el token para que el usuario pueda seguir conectado. Además, hay que complementarlo con otros mecanismo de seguridad ante CSRF más la identificación por desafío clásica hacia una base de datos cuyos datos estén cifrados e incluso, el mismo formulario de identificación manipule el stream de comunicación cifrado. Esto al menos es lo más básico. Luego las claves para generar el JWT tienen que tener más de 20 caraceres y usando caracteres de símbolos cosa que por fuerza bruta sea dificil de cifrar más un salt para el cifrado. El problema aquí no es JWT. El problema es la aplicación que tiene un problema de seguridad terrible y eso tienen que cambiar o corregir. Saludos Miguel.
Solo agrega expiracion, no mandes info sensible por el JWT y si quieres, en el JWT encapsula el IP de donde se hace el request, si un request no tiene el IP del JWT, entonces invalidar el request, una de tantas estrategias
yo tengo configurados los refresh de otra forma, el jwt caduca en una hora, pero si despues de vencer el token has pasado 10 minutos a mas, automaticamente el token no refresca, en ese lapso de 10 min, si se hace una consulta.. mediante un interceptor, el token es analizado y se vuelve a crear un nuevo token con otra hora mas de vida. Me ha gustado mucho el hecho de que nombres el colocar un secret a nivel de usuario.. lo implementare en mis proyectos xD
¿Mi duda es como saber si el token vencido al pedir refresh es del mismo dispositivo? sin guardar una referencia en la BD? ósea el token asfasf2312asd si está firmado con mis llaves secretas y en su payload agrego datos de dispositivos como navegador, IP, etc. un atacante puede leer el payload lo cual no tiene ciencia y simular el User-Agent como mínimo ( lo de la IP no sabria yo como ) para engañar al refresh. . Sigue siempre siendo jodido que te copien el JWT y peor si es junto al Refresh.
Creo que la mejor solución es guardar el iat (Issued At) en el JWT y tener en la base de datos un campo token_validity que por defecto sea la fecha de creación del usuario. Entonces, después de descifrar el JWT, compruebas que el iat sea igual o posterior al token_validity del usuario como validación adicional. De esta forma, con solo actualizar el campo token_validity a la fecha actual invalidas todos los JWT generados hasta ese momento.
@lucaslabs4885 jwt es un gestos tu como programador deberías tener las sessiones en bd o archivos... Todas las cms utilizando el mismo sistema incluso las más simples... En open-source es muy sugerido siempre, con eso tu puedes manejar las sessiones individuales
Puedes guardar los JWT en redis y consultar si esta activo o no cuando lo utilice y como seguridad adicional guardar que dispositivo e ips lo estan utilizando y las consultas a redis son superapidas y no volveria las consultas mas lentas no??
Gente una pregunta, estoy haciendo una app para mi portafolio y quiero que el usuario no tenga que iniciar sesión cuando caduque el refreshToken, quiero que la sesion se mantenga vigente a menos que intente hacer login desde otro dispositivo o ubicación y del resto los tokens de acceso si caducan cada 30min esto que quiero hacer es inseguro? O debería de "sacrificar" en cierto modo la comodidad del usuario haciendolo iniciar sesión para renovar el refreshToken?
Se podria mitigar almacenando el token y la IP del cliente en Redis para que la verificación en el Back sea instantánea en cada petición, así si alguien te roba el token no coincidiría la IP, es una idea solamente.
Lo que yo no entiendo es, yo utilizo los jwt añadiendo el correo y el nombre de usuario, y cuando el usuario manda una solicitud simplemente obtengo el usuario que corresponda con ese correo y nombre de usuario (obviamente tras comprobar que el jwt en si sea correcto), bueno, pues cambiando el correo de la cuenta haria que la informacion ya no sea valida y simplemente ignoraria al usuario. No entiendo que parte de esto es la que impide a kick simplemente cambiar el correo y solucionarlo. Bueno, y ademas de todo esto, deberia haber una fecha limite para el jwt...
Haz un video donde hables mas afondo sobre las mejores practicas para generación de sesiones, tokens y de mas, estoy muy seguro que será muy visto y apoyado
pero no entiendo... por que no le ponen caducidad corta, usas la lógica del access/refresh token y seteas la cookie como httpOnly, SameSite y Secure? Aunque te hackeen la cookie de alguna manera, solo podrían tener acceso a tu cuenta por el rato que dure el token y luego ya no podrian autenticarse
8:38 Esto tambien se puede hacer con cookies normales de toda la vida y sesiones del lado del servidor, no se por qué la gente se complica tanto No me malinterpreten, JWT existe por una razones importantes pero TODO EL MUNDO va y lo usa como si fuera la unica opción y sin saber nada básico de seguridad
Interesante lo descrito, igualmente me parece mejor ocupar todo el hash en la seguridad en vez de lo que hace JWT que incluye la informacion desencriptada y los headers, aunque yo programe algo parecido en JWT entre apps
No hay necesidad de cambiar el secret, se puede hacer un if qué cuando sea la cuenta de tanizen se borren las cookies o de lo contrario tener una lista de tokens bloqueados para este tipo de casos y devolverle un 401 hay formas lo q es en un lugar crucial de la infraestructura y el miedo a romper algo y perder millones es complicado
Hola midu eres siempre una fuente confiable de informacion y conocimiento. Deberias hacer un video de las buenas practicas al momento de usar JWT. Saludos
JWT de corta duración, unos 30 minutos, con un refresh token y listo. Sin pones información confidencial en el payload. Si te roban el token invalidas el refresh token. JWT solo permite transportar información con la confianzan de que no ha sido modificada en el proceso, no es una solución completa de autenticación en la web, que se use para eso es otra historia, pero debe ir acompañado de más técnicas.
Las tipicas y seguras sesiones de usuario por parte del servidor. El problema es que es mas costoso. La ventaja es que es mucho mas seguro y fácil de implementar.
tengo una duda, por ejemplo en Firefox existe lo de la multi acount que son contenedores que pueden tener secciones separadas muy conveniente cuando quieres tener multicuentas de un mismo sitio, es posible robarse esta cookies ya que viendo el local storage de cada contenedor parece ser que no se comparten ademas de que para acceder a al local storage usando la terminal tienes que estar activado el contenedor al cual quieres acceder al local-storage de lo contrario solo estarás accediendo al default que es el navegador sin contenedor
Entonces me estás diciendo que un día alguien del equipo de kick dijo, cuando cierren sesión solo voy a destruir el token, no lo voy a blacklistear y con dos bien grandes me quedo tan limpito. Y a los de auditoría en seguridad qué les pasó? Ni en las API que hice en la universidad me tuve tanta confianza te voy diciendo.
por lo que entiendo la unica forma de tener seguridad es teniendo ese token con criptografia en un servidor y pasarlo al cliente. y que entre el cliente y servidor en cada consulta cambie. pero eso lo tiene que hacer uno, nosotros usamos el sistema de cyberark para hacer esto mismo y estamos en una fase de prueba para hacerlo con certificados
No le veo sentido actualizarlo en cada petición. Aparte usar RSA tiene sentido si necesitas que algún tercero necesite validar la firma además de quien lo ha emitido, ya que usa llaves asimétricas. Si ese no es el caso, usar HS256 sería más factible y performante
A mí me pasó que me robaron la sesión de Facebook y LinkedIn y algo increíble es que lograron cambiar de correo electrónico en Facebook no le pidió una confirmación mfa o algo , simplemente me lo cambio Era muy evidente el hackeo porque derrepente la cuenta fue accedida desde Vietnam y a Facebook le pareció normal , al final tiene algo chévere que es bloquear la cuenta si no puedes acceder y así se pudo invalidarle la sesión Tenía mfa activa
Que tal si le ponen la condicion desde kick, cuando sea este usuario el tal 'cebollo' ese te envio nuevo token con tiempo de expiracion 0 o negativo. Eso para empezar. 2° implementar mas seguridad en el login, que cuando se loguee en un dispositivo se envie en el formulario la mac de ese dispositivo, ya que esa es unica, ahora en cada token no envies la Mac, solo dejala en tiempo de session anotada en base de datos tipo a cada ID_SESSION unica, perteneciente a un usuario ID_USER, le corresponde una MAC y entonces un token puede llevar el ID_USER Y ID_SESSION, y consultar antes de dar respuesta desde el servidor si la MAC consultada corresponde a la anotada en BD como el trio ID_USER, ID_SESSION, MAC...
Los JWT como todo en la vida, no te cubren por si solos el 100% de casos de usos, hay servicios en los que conviene hacer validaciones adicionales sobre ellos y es totalmente válido. Recuerden que lo importante de esta tecnologia es garantizar que los datos que compartes no son modificados.
En ese caso ya se está almacenando estado en el server, que es algo que se quiere evitar con los JWT, personalmente prefiero usar sesiones mientras el caso de uso lo permita
@@victor_ls Lo mismo puede suceder con las sesiones y cookies sino las configuras bien y les estableces tiempos cortos de uso. Es menos frecuente, sí, con el uso de httpOnly, pero siguen siendo vulnerables de todas maneras, esto ya es más un problema de mal implementación que de las herramientas en si.
yo para los jwt que no expiran, creo una clave aleatoria que solo funciona para ese jwt (codificarlo y decodificarlo)y se almacenan los dos en bd, asi no dependes de una variable global para crear el token y despues puedes invalidar sin efectos
La verdad es que sigo sin entender mucho los jwt he pasado días y noches pensando en una solución segura pero todo el mundo tiene problemas de como implementarlos. Y la verdad es que es costoso hacerlo. No es un metodo fácil ni mucho menos barato de implementar. No se metan en el jwt gente si su web trata datos sencibles. Los youtubers que te enseñan a implementarlo dicen que es fácil pero es todo lo contrario.
Yo lo que hago es Tener el acces token en 15 minutos y el refresh guardado en http only, cuando se hace una petición al servidor miro el token y si es válido lo renuevo con el refresh. Es fácil que te roben el access pero el refresh es más complejo que te lo roben. Todavía no tengo un proyecto que necesite más seguridad
La solucion mas facil es que ahora mismo agreguen un token por usuario y le asignen como secret token individual a TODOS el mismo del general y generen el JWT firmando con general+individual (lo validen de la misma forma), luego para el caso de Tanizen cambiarle su token individual y listo...
Creo que solo me tocó implementar jwt una o dos veces. En mi caso lo hice que primero deba iniciar sesión, luego recién podía pedir el jwt, y el jwt expiraba en 15 minutos. No se si es de las mejores prácticas, pero por lo que pude ver parece funcionar ok.
Che pero si cambian el secret y cierran la session de todos que tiene de malo? solo cada persona deberia volver a colocar el usaurio y password y volver a logearse, no es algo tan grave eso. Si fuese kick haria eso y listo.
Una forma "sencilla" y factible de usar JWT es: Nunca debería ser infinitos y tener una duración corta y renovable una única vez, da igual si tiene información como ID de usuarios pero evitar cargarlo de información innecesaria, debes agregar una lógica extra en el Server para invalidarlos individualmente como revisando si ese JWT es valido aun (contra un Redis y no contra una DB por ejemplo)
pero a ver: que te cuesta hacer que si a cuenta x se conecta, desloguearla y borrar su jwt? Por cierto, es lo que dicen de las credenciales: no guardan la IP de donde se conectan (problema que tmb surge con los bancos)
Pero no entendi, entonces cual es la correcta practica para gestionar esto a nivel de codigo? JAJAJAJAJ ya tenemos material para un tallersito en live!
![I Built a Secret Room in the Garage [Cinema + Bunker]](/img/1.gif)
Creo que esta super claro que es un tema que la comunidad necesita , Por favor midu un video/curso sobre este tema y las mejores practicas, no tienes que ser super extenso pero si que nos deje el camino para seguir investigando o algunos referentes
Los JWT deben tener cierta vida, no vida ilimitada. Eso es relativamente básico en autenticación y autorización.
Si a las cookies que tienen tiempo de vida les pasa lo mismo. El tema es que la información que viene dentro de los jwts deberían estar encriptadas o agregarle algunos niveles mas de seguridad.
Si y no.
Es casi lo mismo con twitch donde tambien tiene las sesiones de vida util ilimitado.
Aun que sí desconosco lo del develop de la estructura de las sesiones en twitch.
Aun que para diferentes plataformas que sean. Deberian ser com vida util limitada.
Pero hay algunas apps que renuevan el JWT si es valido y entrega uno completamente nuevo con un nuevo tiempo de expiración. Para mantener la sesión iniciada si esta en constante uso
@@cesar7111pues como todo en la vida, hay pros y contras.
Si quieres seguridad pierdes experiencia de usuario.
Y si quieres experiencia de usuario, necesitas tener mecanismos que solventen los problemas de seguridad.
no suelen tener vida ilimitada, si no de 24 horas a 7 dias
Recuerdo haber leído un tweet de Matteo Collina donde decía que le daba miedo la cantidad de brechas de seguridad que podrían existir en un futuro por culpa de “RUclipsrs” o “influencers” que tenían video/cursos donde implementaban sistemas de autenticaciones con vulnerabilidades. Ya veo que tenía razón
Muy cierto, qué preocupante, todo por no hacer la implementación correcta y ahorrar tiempo en el video
muy interesante lo que explicas. me acuerdo que en el curso de node nos quedamos en las cookies (no de terceros) y dijiste que hariamos "sesiones" en la próxima clase. y ya hace no sé cuanto que estoy esperando que sigas el curso y expliques lo de las sessions. molaria un repaso practico de todo esto que has contado, con código usando supabase mismo ya que reexplicar esto puedes evitarte errores muy jodidos como lo que explicas :)
hay que pagarrr para eso
Ahhh pero queres poco bro jajajajja
tanto ha pasado que ya podrías haberlo hecho tu mismo jajaja
Buscalo en internet como hacerlo, en inglés hay millones de páginas que enseñan todo
Tanto costaba hacer tokens de refresco o autenticación dinámica
La plata de los casinos no da para tanto.
hola
hay alguna forma recomendada de aprender de eso en cuanta al timepo de expiracion y mas ?
redis whitelist ...
en caso si el client es un movil
Oro puro, seria interesante que un dia hagas unos ejemplos de este tipo de seguridad
Por eso es importante conocer los RFC, prácticas de implementación sobre JWT, JWE, JWS y más
Midu, me gustaria que hicieras un video o algo relacionado con ejemplos sobre como persistir o usar jwt, creo que la comunidad lo necesita. Gracias
Hace un par de años desarrollando un proveedor de identidad me encontre con problemas similares. Consultando bastante diversas opciones de cara a securizar me encontre con lo que llaman BFF (Backend for Frontend) que basucamente consiste en tener un proxy inverso entre cliente y servidor. Este proxy almacena los JWT y los resfrestokens y al cliente solo le pasan la cookie con un tiempo limitado, aumentando al final la seguridad de no pasarle esa info al cliente. Obviamente tiene sus contras como es tener un mayor delay al tener el rpoxy inverso entre cliente y servidor pero para este tipo de situaciones creo que merece mucho mas la pena, teniendo en cuenta que a dia de hoy manejamos altas velocidades.
Otra cosa (aqui ya no recuerdo si funcionaba asi) es la posibilidad de dar de baja los persistence tokens en la bbdd del proveedor de identidad.
Flipo que kick tenga este tipo de problemas teniendo en cuenta la cantidad de pasta que tienen que manejar
Midu buen video informativo, ojalá hicieras un video explicando las buenas prácticas de seguridad para auth, un saludo
La expiración del JSON Web Token (access token) debe ser de minutos (unos 5), el refresh token que se usa para renovar el access token debe almacenarse unicamente en una http only cookie de esa manera javascript no puede leerlo ni modificarlo.
Hermano como sabes que admiración, que increíble la experiencia y conocimiento que tienes crack
Los JWT podrán ser muy buenos siempre y cuando les des un buen uso.
Como Backend para mayor seguridad, tengo una Secret General y una Secret a nivel de usuario el cual es un GUID a base de la contraseña (Así si lo reinician, cambia). Los concateno y es la secret del JWT además tienen una expiación dependiente del tipo de software. Además tengo el device_ID qué es una concatenacion de igual manera. Luego al momento de pasar a realizar peticiones. Consulto a la base de datos con el usuario que me llega. Y hago las respectivas validaciones y concatenaciones.
Podrá mi aplicación ser unos milisegundos más lenta, pero es más segura.
Esto es como el conducir, primero la seguridad y luego la velocidad.
@midulive !, tienes alguna clase de esto?? seria genial una clase corta de esto!
Un JWT con expiración de 1 semana. Fin. Y si ocurre esto, se banea la cuenta original temporalmente hasta que expire. Mucha ingeniería en Kick pero lo más básico no lo hacen.
Yo aprendi hace meses JWT y ya desde al principio aprendí a ponerle tiempo de expiración al Token 🤣
Banear la cuenta hasta que expire significaría dejar al usuario también sin acceso. Ademas cómo baneas la cuenta si estas usando jwt sin estado ni interacción con la base de datos? 1 semana es un período de expiración demasiado largo si se usa un único jwt y también tiene el problema de información desactualizada (por ejemplo el usuario cambia de mail pero en el jwt sigue teniendo el mail anterior por una semana entera). La solución mas básica es tener token de acceso con 5-10 minutos de expiración y un refresh token que al verificarlo y si está expirado el de acceso, se hace una petición a la base de datos para renovar el token de acceso ( debe estar el secret del refresh token en la base de datos asociado al usuario ).
De esa forma si el secret del refresh token es inválido, no se renueva y por lo tanto se cierra la sesión, dandole a un posible hacker como máximo 5-10 minutos de usar la cuenta del usuario. Esto se puede ampliar dandole más funcionalidades como limite de tokens y dispositivos.
creo que lo mejor sería no abrir correos sospechosos :P
Factos, desde que S4vitar cayó en uno de éstos, simplemente pienso que es un poco tonto caer eso :v
en el estandar de JWT hay un campo que se llama JTI (Json Token Identifier) que se puede incluir en los token JWT; este campo, es basicamente pues eso un identificador que te puedes guardar por ejemplo en base de datos en el lado del servidor y seguir una estrategia de lista blanca o lista negra (esto ya a gusto de cada uno y segun sus necesidades) para si existe el JTI en base de datos y el token es valido (esto es si fuera usando la estrategia de lista blanca), considerarlo valido. Aunque tambien es verdad que el utilizar este campo hace que pierda la naturaleza stateless de un token JWT ...
Que opinas de guardar los jwt en la base de datos para validarlo y dado el caso de ser necesario se inválida o elimina de la base de datos y el usuario no podrá ingresar.
Igual me equivoco, pero creo que el problema no está en JWT (que hace lo que tiene que hacer), sino en la (posible) implementación de OAuth (o sucedáneo). Lo que comentas de refrescar, cambiar, banear, etc se hace con el servicio de autenticación (y dependen de cómo esté implementado el servicio y su autorización).
Por proponer cosas, sin más.
Gracias por tus videos.
creo que la forma correcta de trabajar con tokens JWT (para implementar seguridad en una app) es usando el protocolo OpenID Connect
Por lo general, mi enfoque consistía en limitar el acceso a múltiples dispositivos, aunque entiendo que esta práctica puede resultar tediosa para el usuario. Implementaba un sistema basado en tokens generados por el navegador. Por ejemplo, si ya existían varias sesiones activas (incluyendo la del JWT), almacenaba información tanto del navegador como del dispositivo desde el cual se accedía. Esto me permitía identificar el origen y momento del ingreso de un usuario y evitar que utilizara sus credenciales de forma indiscriminada en diferentes dispositivos.
En caso de que se necesitara finalizar la sesión de un usuario en un dispositivo específico, simplemente eliminaba el token asociado a ese navegador o dispositivo. Esto cerraba automáticamente la sesión, ya que la validación del token estaba vinculada a cada dispositivo. Si el token ya no existía o no estaba activo, el acceso se bloqueaba de forma efectiva.
Esto se podría haber evitado usando una maquina virtual para abrir dicho documento? Tipo Windows Sandbox o VirtualBox?
Me tocó ver como hacíamos el cambio a auth con jwt y con un poco de investigación para montarlo ya podía llegar a ver esos problemas…
Al final optamos por tener un jwt que dura minutos (quizás excesivamente corto, pero refrescarlo no cuesta realmente), y un refresh de un solo uso que dure una semana. Si tenemos que cerrar la session de alguien, borramos su refresh en la base de datos y listo.
En algún momento para controlar distintos dispositivos que tengan la sesión abierta a la vez pues simplemente tener unos por usuario y dispositivo.
Igual es porque planteamos las cosas en modo paranoico, pero no es tan difícil, es triste que empresas grandes no se paren a pensar en el usuario malicioso antes de hacer estas cosas…
Recomendaría refresh tokens o sliding tokens, ya que así de cierta forma siempre se valida con la bd el estado del token y asi evitamos este tipo de cosas
¿Cuando se viene tutorial del tema de JWT tokens y refresh tokens y como hacerlo bien?
Si tienen un isActive en la tabla de usuarios y se pone a false, al hacer el refresh token y consultar a la tabla de usuarios, no estaria autorizado.
Tengo un proyecto y guardo información del propio usuario en el local storage a modo de caché para ahorrar peticiones a la db cuando no hay cambios, no es información confidencial, pero si privada, la información está cifrada con CryptoJS. Mi pregunta es, qué tan seguro es este método?
Como mencionas el problema es como han implementado su uso.
Apenas estoy aprendiendo jwt 🙂
X2
No te preocupes lo que pasó con Kick fue por no hacer las cosas bien, lo que si te diría es que investigues que cabeceras viajan en cada petición y cuáles puedes usar para autenticar al usuario (saber si es el en realidad y no un hacker)
tambien quiero aprender eso
primeor la estrctura.
yo esuche algo de B2C credentials pero mas perdido estoy
bueno pues te recomiendo que los jwt solo deben durar 15 minutos o máximo 30, el que debe de durar aprox 7 días es el refresh token, lo que le paso a KICK fue algo demasiado básico.
@omartorresrios8216 El refresh token que información debe poseer y cual es su uso? Se envía en cada petición o como funciona?
En PcComponentes pasa exactamente lo mismo. Un tío tenía mi cuenta abierta, y podía hacer pedidos con mi tarjeta guardada después de cambiar la contraseña y la del correo. No tienen forma de invalidar la sesión, y aun guardando tarjetas de crédito, no tienen MFA.
No quedó otra que borrar las tarjetas y olvidar la cuenta, ya no es segura. Ha sido este mes, por cierto.
y si encriptamos el jwt en el lado del cliente? ya no seria factible robarlo desde el local o session storage, ademas si el jwt le ponemos una vida de solo unos minutos y al refresh una mas larga, pero guardandola en bd, eliminandola desde bd podemos mitigar el acceso del jwt y solicitar inicio de sesion nuevo
Yo almacenó el token en Redis y luego después de su uso, lo dejo un tiempo en una blacklist, por si aún le queda algo de vida
Si bien es un caso aislado, al conocimiento que jwt podría ser vulnerado existe ya hace rato, empecé a usar paseto por lo mismo, ahora, independientemente de ello, cualquier tecnología será insegura y/o mala si no se implementa bien. Kick se acaba de dar no un disparo si no un escopetazo de PR en el pie.
El que lo programo así mi primera chamba
Recuerdo que Midu hizo un ejemplo en Node con JWT hace mucho tiempo y si mi memoria no me falla, el comento que estaba pendiente el refresh token. Cuando el tenga tiempo, y si le apetece, seria interesante ver como se implementaria el refresh y medidas de seguridad o documentacion para disminuir las fallas que tuvieron en kick
Lo que yo he visto para evitar estos casos es:
- tokens de duración corta (unos cuantos minutos), usando un secret "compartido"
- + refresh tokens con una duración más larga, usando como secret un hash creado a partir del hash del password del usuario
De esta forma, si el password del usuario cambia, el refresh token automáticamente queda inválidado.
En este caso, un administrador de kick podría cambiarle el password al usuario hackeado y así invalidaría todos los refresh tokens. Es decir, en cuestión de minutos el token principal vence y es imposible refrescarlo con un refresh token anterior al cambio de password.
Entonces sería un sistema más parecido al SSH. También se podría incluir un payload en el token con la IP o algún dato que identifique el dispositivo. Además de tener una expiración corta.
Sale un midulive para mostrar cómo hacerlo?
El usar un secret por usuario solucionaría el tema de no poder desloguearse.
Normalmente se toman parte del Id del usuario o en combinación con otro campo unico
Que animal no usa salt si usa jwt.. es súper básico tener no solo secreto general sino particular para usuario (salt)
Como estándar se debe manejar que la expiración sea de una hora. Además que mal kick al no añadir la opción de cerrar sesión de todos los dispositivos que se registren en la cuenta.
En el proyecto para la empresa en la que trabajo, implemente JWT tokens, pero con sesiones corta 30 minutos de instintiva, sesión única, recuperación de sesión por correo electrónico, 2FA, y verificación del token en base de datos, de además de poder cerrar sesión desde la base de datos, esto último sacrifica velocidad, pero la seguridad es primero y más para un ERP
Los JWT tienen que utilizarse con un mecanismo de "renovación" de los tokens cada 30 minutos. Eso evita que el token generado se pueda reutilizar. El problea es que los token generados no se pueden eliminar del servidor una vez tu te desconcetas o cierras la sesión. Por eso se recomienda primero, poner tiempos de utiliza del token no mayor a 30 minutos y luego cerrar la sesión automáticamente o bien, regenerar el token para que el usuario pueda seguir conectado. Además, hay que complementarlo con otros mecanismo de seguridad ante CSRF más la identificación por desafío clásica hacia una base de datos cuyos datos estén cifrados e incluso, el mismo formulario de identificación manipule el stream de comunicación cifrado. Esto al menos es lo más básico. Luego las claves para generar el JWT tienen que tener más de 20 caraceres y usando caracteres de símbolos cosa que por fuerza bruta sea dificil de cifrar más un salt para el cifrado.
El problema aquí no es JWT. El problema es la aplicación que tiene un problema de seguridad terrible y eso tienen que cambiar o corregir. Saludos Miguel.
He notado como a algunos RUclipsrs le han llegado a secuestrar la cuenta, lo que muestra lo complicado que es mantener la seguridad de un sitio web.
Justo cuando acabo de implementar JWT en mi proyecto 🗿🗿🗿🗿🗿🗿🗿🗿
💀
Solo agrega expiracion, no mandes info sensible por el JWT y si quieres, en el JWT encapsula el IP de donde se hace el request, si un request no tiene el IP del JWT, entonces invalidar el request, una de tantas estrategias
@@Gabozxc lo tengo de 24h la expiración y respecto a las tecnicas ya acabas de darme algunas ideas, gracias mi brother 🧐🍷
@@Gabozxc Pero si usa ip dinámica lo invalidas también?
😂😂😂😂😂😂
Aparte de la duración, no entiendo por qué no agregan la IP de usuario. No es 100% efectivo pero no deja de ser una medida extra.
Un curso de jwt estaría bueno midu
yo tengo configurados los refresh de otra forma, el jwt caduca en una hora, pero si despues de vencer el token has pasado 10 minutos a mas, automaticamente el token no refresca, en ese lapso de 10 min, si se hace una consulta.. mediante un interceptor, el token es analizado y se vuelve a crear un nuevo token con otra hora mas de vida. Me ha gustado mucho el hecho de que nombres el colocar un secret a nivel de usuario.. lo implementare en mis proyectos xD
En el curso de aprende a usar jwt en node que tiene midu enseña a usarlos bien?
¿Mi duda es como saber si el token vencido al pedir refresh es del mismo dispositivo? sin guardar una referencia en la BD? ósea el token asfasf2312asd si está firmado con mis llaves secretas y en su payload agrego datos de dispositivos como navegador, IP, etc. un atacante puede leer el payload lo cual no tiene ciencia y simular el User-Agent como mínimo ( lo de la IP no sabria yo como ) para engañar al refresh. . Sigue siempre siendo jodido que te copien el JWT y peor si es junto al Refresh.
Creo que la mejor solución es guardar el iat (Issued At) en el JWT y tener en la base de datos un campo token_validity que por defecto sea la fecha de creación del usuario. Entonces, después de descifrar el JWT, compruebas que el iat sea igual o posterior al token_validity del usuario como validación adicional. De esta forma, con solo actualizar el campo token_validity a la fecha actual invalidas todos los JWT generados hasta ese momento.
Hasta los cms más básicos tienen una función para borrar el token del usuario solamente
Es que la idea del json web token es que no guardes el token.... en otras palabras: no hay nada que pueda ser borrado.
@lucaslabs4885 jwt es un gestos tu como programador deberías tener las sessiones en bd o archivos... Todas las cms utilizando el mismo sistema incluso las más simples... En open-source es muy sugerido siempre, con eso tu puedes manejar las sessiones individuales
Puedes guardar los JWT en redis y consultar si esta activo o no cuando lo utilice y como seguridad adicional guardar que dispositivo e ips lo estan utilizando y las consultas a redis son superapidas y no volveria las consultas mas lentas no??
Yo pensaba en usar redis como caché pero solo a modo blacklist, no todos los tokens sino los invalidados y así reducir el "diccionario"
Gente una pregunta, estoy haciendo una app para mi portafolio y quiero que el usuario no tenga que iniciar sesión cuando caduque el refreshToken, quiero que la sesion se mantenga vigente a menos que intente hacer login desde otro dispositivo o ubicación y del resto los tokens de acceso si caducan cada 30min esto que quiero hacer es inseguro? O debería de "sacrificar" en cierto modo la comodidad del usuario haciendolo iniciar sesión para renovar el refreshToken?
Cuando Kick quiere usar el JTW como “caché distribuido”
Se podria mitigar almacenando el token y la IP del cliente en Redis para que la verificación en el Back sea instantánea en cada petición, así si alguien te roba el token no coincidiría la IP, es una idea solamente.
Mediante un redis puedes marcar los token como inválidos. Al cerrar sesión o cambiar de contraseña
Pero esas cookies no se setean por protocolo https?....o sea q si copias y pegas las cookies no sirve xq se estarían seteando por el front
Tengo entendido que esto en Firefox no pasa debido al sandbox para las cookies. ¿Alguien sabe si esto es cierto?
Si el caso es que JWT solo lo utiliza para el front, el problema no sería difícil de resolver.
El error seguro es porque el junior le puso a la cookie SameSite = none XD
Lo que yo no entiendo es, yo utilizo los jwt añadiendo el correo y el nombre de usuario, y cuando el usuario manda una solicitud simplemente obtengo el usuario que corresponda con ese correo y nombre de usuario (obviamente tras comprobar que el jwt en si sea correcto), bueno, pues cambiando el correo de la cuenta haria que la informacion ya no sea valida y simplemente ignoraria al usuario. No entiendo que parte de esto es la que impide a kick simplemente cambiar el correo y solucionarlo.
Bueno, y ademas de todo esto, deberia haber una fecha limite para el jwt...
Por eso existe el accestoken, el Autorefreshtoken, protected, etc
Haz un video donde hables mas afondo sobre las mejores practicas para generación de sesiones, tokens y de mas, estoy muy seguro que será muy visto y apoyado
pero no entiendo... por que no le ponen caducidad corta, usas la lógica del access/refresh token y seteas la cookie como httpOnly, SameSite y Secure? Aunque te hackeen la cookie de alguna manera, solo podrían tener acceso a tu cuenta por el rato que dure el token y luego ya no podrian autenticarse
8:38 Esto tambien se puede hacer con cookies normales de toda la vida y sesiones del lado del servidor, no se por qué la gente se complica tanto
No me malinterpreten, JWT existe por una razones importantes pero TODO EL MUNDO va y lo usa como si fuera la unica opción y sin saber nada básico de seguridad
Interesante lo descrito, igualmente me parece mejor ocupar todo el hash en la seguridad en vez de lo que hace JWT que incluye la informacion desencriptada y los headers, aunque yo programe algo parecido en JWT entre apps
tal cual ! programación y contraprogramación Smith
No hay necesidad de cambiar el secret, se puede hacer un if qué cuando sea la cuenta de tanizen se borren las cookies o de lo contrario tener una lista de tokens bloqueados para este tipo de casos y devolverle un 401 hay formas lo q es en un lugar crucial de la infraestructura y el miedo a romper algo y perder millones es complicado
Hola midu eres siempre una fuente confiable de informacion y conocimiento. Deberias hacer un video de las buenas practicas al momento de usar JWT. Saludos
podría cada user tener su llave e invalidarla, pero implica una llamada a la db en cada request y es costoso
JWT de corta duración, unos 30 minutos, con un refresh token y listo. Sin pones información confidencial en el payload. Si te roban el token invalidas el refresh token.
JWT solo permite transportar información con la confianzan de que no ha sido modificada en el proceso, no es una solución completa de autenticación en la web, que se use para eso es otra historia, pero debe ir acompañado de más técnicas.
Entonces cuál es la alternativa a JWT?
Las tipicas y seguras sesiones de usuario por parte del servidor. El problema es que es mas costoso. La ventaja es que es mucho mas seguro y fácil de implementar.
midu deberías hacer un video de cómo ver la ubicación y ver si es vpn desde la web
tengo una duda, por ejemplo en Firefox existe lo de la multi acount que son contenedores que pueden tener secciones separadas muy conveniente cuando quieres tener multicuentas de un mismo sitio, es posible robarse esta cookies ya que viendo el local storage de cada contenedor parece ser que no se comparten ademas de que para acceder a al local storage usando la terminal tienes que estar activado el contenedor al cual quieres acceder al local-storage de lo contrario solo estarás accediendo al default que es el navegador sin contenedor
Entonces me estás diciendo que un día alguien del equipo de kick dijo, cuando cierren sesión solo voy a destruir el token, no lo voy a blacklistear y con dos bien grandes me quedo tan limpito. Y a los de auditoría en seguridad qué les pasó?
Ni en las API que hice en la universidad me tuve tanta confianza te voy diciendo.
por lo que entiendo la unica forma de tener seguridad es teniendo ese token con criptografia en un servidor y pasarlo al cliente. y que entre el cliente y servidor en cada consulta cambie.
pero eso lo tiene que hacer uno, nosotros usamos el sistema de cyberark para hacer esto mismo y estamos en una fase de prueba para hacerlo con certificados
Yo uso JWT con RSA y lo actualizo cada petición. Además de encriptarlo de punto a punto con un algoritmo híbrido RSA con AES
si escala haciendo un nuevo token en cada petición al servidor?
No tiene mucho efecto en el rendimiento del servidor si tenés múltiples peticiones de una cantidad de usuarios amplia?
el JWT debe tener una vida útil, generar un JWT tiene un costo en el servidor
No le veo sentido actualizarlo en cada petición. Aparte usar RSA tiene sentido si necesitas que algún tercero necesite validar la firma además de quien lo ha emitido, ya que usa llaves asimétricas. Si ese no es el caso, usar HS256 sería más factible y performante
A mí me pasó que me robaron la sesión de Facebook y LinkedIn y algo increíble es que lograron cambiar de correo electrónico en Facebook no le pidió una confirmación mfa o algo , simplemente me lo cambio
Era muy evidente el hackeo porque derrepente la cuenta fue accedida desde Vietnam y a Facebook le pareció normal , al final tiene algo chévere que es bloquear la cuenta si no puedes acceder y así se pudo invalidarle la sesión
Tenía mfa activa
Yo tenia una cuenta publicitaria en FB y me sacaron como admin de esa cuenta y la usaban para publicitar casinos
Que tal si le ponen la condicion desde kick, cuando sea este usuario el tal 'cebollo' ese te envio nuevo token con tiempo de expiracion 0 o negativo.
Eso para empezar.
2° implementar mas seguridad en el login, que cuando se loguee en un dispositivo se envie en el formulario la mac de ese dispositivo, ya que esa es unica, ahora en cada token no envies la Mac, solo dejala en tiempo de session anotada en base de datos tipo a cada ID_SESSION unica, perteneciente a un usuario ID_USER, le corresponde una MAC y entonces un token puede llevar el ID_USER Y ID_SESSION, y consultar antes de dar respuesta desde el servidor si la MAC consultada corresponde a la anotada en BD como el trio ID_USER, ID_SESSION, MAC...
Los JWT como todo en la vida, no te cubren por si solos el 100% de casos de usos, hay servicios en los que conviene hacer validaciones adicionales sobre ellos y es totalmente válido.
Recuerden que lo importante de esta tecnologia es garantizar que los datos que compartes no son modificados.
Bueno, hemos aprendido que los de Kick no saben usar JWT. se pueden invalidar con un servicio que te de una clave-valor como lo hacia Redis
En ese caso ya se está almacenando estado en el server, que es algo que se quiere evitar con los JWT, personalmente prefiero usar sesiones mientras el caso de uso lo permita
@@victor_ls Lo mismo puede suceder con las sesiones y cookies sino las configuras bien y les estableces tiempos cortos de uso.
Es menos frecuente, sí, con el uso de httpOnly, pero siguen siendo vulnerables de todas maneras, esto ya es más un problema de mal implementación que de las herramientas en si.
yo para los jwt que no expiran, creo una clave aleatoria que solo funciona para ese jwt (codificarlo y decodificarlo)y se almacenan los dos en bd, asi no dependes de una variable global para crear el token y despues puedes invalidar sin efectos
La verdad es que sigo sin entender mucho los jwt he pasado días y noches pensando en una solución segura pero todo el mundo tiene problemas de como implementarlos. Y la verdad es que es costoso hacerlo. No es un metodo fácil ni mucho menos barato de implementar. No se metan en el jwt gente si su web trata datos sencibles. Los youtubers que te enseñan a implementarlo dicen que es fácil pero es todo lo contrario.
Con un JWT blacklist se resuelve
Tambien es buena práctica anular los jwt a partir de iat del usuario.
para eso no uses jwt, una blacklist tiene mas sentido usarla con los refresh tokens que tienen mas duracion y generan menos carga en el servidor
algun patron de diseño ayuda a solucionar esto?? me refiero a que no tengan que cerrar todas las cuentas de kick
Eventualmente van a tener que cambiar la frase secreta de JWT para parchear esa seguridad, porque no ahora
Aquí los que apenas acabamos de aprender JWT. 👀
Yo lo que hago es Tener el acces token en 15 minutos y el refresh guardado en http only, cuando se hace una petición al servidor miro el token y si es válido lo renuevo con el refresh. Es fácil que te roben el access pero el refresh es más complejo que te lo roben. Todavía no tengo un proyecto que necesite más seguridad
La solucion mas facil es que ahora mismo agreguen un token por usuario y le asignen como secret token individual a TODOS el mismo del general y generen el JWT firmando con general+individual (lo validen de la misma forma), luego para el caso de Tanizen cambiarle su token individual y listo...
Te imaginas alquilar tu departamento y nunca pedirles que te devuelvan las llaves o cambiar la combinación de la cerradura? ... Bueno así
Que alternativas hay a jwt?
Un secret poe usuario rompe el concepto de JWT, tendrías que ir a consultar a la base
Creo que solo me tocó implementar jwt una o dos veces. En mi caso lo hice que primero deba iniciar sesión, luego recién podía pedir el jwt, y el jwt expiraba en 15 minutos. No se si es de las mejores prácticas, pero por lo que pude ver parece funcionar ok.
Che pero si cambian el secret y cierran la session de todos que tiene de malo? solo cada persona deberia volver a colocar el usaurio y password y volver a logearse, no es algo tan grave eso. Si fuese kick haria eso y listo.
Una forma "sencilla" y factible de usar JWT es: Nunca debería ser infinitos y tener una duración corta y renovable una única vez, da igual si tiene información como ID de usuarios pero evitar cargarlo de información innecesaria, debes agregar una lógica extra en el Server para invalidarlos individualmente como revisando si ese JWT es valido aun (contra un Redis y no contra una DB por ejemplo)
pero a ver: que te cuesta hacer que si a cuenta x se conecta, desloguearla y borrar su jwt? Por cierto, es lo que dicen de las credenciales: no guardan la IP de donde se conectan (problema que tmb surge con los bancos)
No se puede leer una cookie de un dominio diferente al que estas... hicieron algo mas me parece... podrias ser algun tema de DNS...
Pero no entendi, entonces cual es la correcta practica para gestionar esto a nivel de codigo? JAJAJAJAJ ya tenemos material para un tallersito en live!
y el streamer no tenia sesion iniciada en su celular? o solo se puede tener 1 sesion activa?