Buenas prácticas y riesgos de los JSON Web Tokens (JWT)
Curso de OAuth 2.0 y OpenID Connect: Flujos de Autenticación y Casos de Estudio
Contenido del curso
Curso de OAuth 2.0 y OpenID Connect: Flujos de Autenticación y Casos de Estudio
Clase 22 de 25
Clase 22 / 25
Luis Fernando Castañeda Castro
Gabriel Esquivel
Irving Juárez
Kengya Moncada
Juan Marcelo Panasiti
Almendra Lucía Estrada Navarro
Nicolas Gonzalez
Nahuel Brandan
José David Ripalda Fernández
Axel Nava Palacios
Angel Javier Sanchez Tenjo
Alexander Toro
Si, me gustaría el curso sobre JWT y el Framework JOSE (Javascript Object Signing and Encryption)
Si no me equivoco en todos los cursos de frontend almacenan el JWT en el localStorage, viene Guillermo y dice no es seguro, ahora no sé qué pensar.
Creo que en cursos de puras SPAs, donde no se toca backend, se guardaban ya sea en un session storage o en una cookie del lado del cliente.
Pero si se puede hacer de una manera más segura del lado del servidor con una app fullstack, creo que es mucho mejor
depende... hay librerias que te permiten guardar el token "manera segura" por ejemplo typescript-cookies hace ese trabajo.
Con eso de que un jwt no debería durar más de 15 minutos y de que no se debería almacenar en un local storage.. cómo hacen apps como platzi que aunque me logee ahora, vea un par de videos y cierre todo hasta mañana.. cuando vuelva a abrir la page de platzi sigo teniendo la sesión activa?
Para realizar llamadas seguras a tu API sin almacenar el access token en el frontend, puedes considerar las siguientes estrategias:
Cookies Seguras: Almacena el token en una cookie con la bandera HttpOnly. Esto impide que scripts del lado del cliente accedan a la cookie, reduciendo el riesgo de ataques XSS.
Almacenamiento en Memoria: Guarda el token en la memoria del cliente (por ejemplo, en un estado de React). De esta forma, el token no persiste y solo está disponible durante la sesión activa.
Backend Proxy: Realiza las llamadas a la API desde un servidor backend que maneje los tokens. El frontend se comunica con tu servidor backend, que a su vez se encarga de interactuar con la API.
Estas prácticas ayudan a minimizar el riesgo de exposición del access token y a mantener la seguridad de tu aplicación.
Un ejemplo de uso de los JWT podria ser cuando un cliente se autentica en un sitio web y la aplicacion le asigna un token, este token se almacena del lado del cliente y funciona para futuras solicitudes que realize, pues al tener ya un token de autenticacion este mismo se utilizara para validar la identidad del cliente.
Creo que en este ejemplo estás diciendo cliente cuando en realidad quieres decir usuario.
Si es que no quisiera que la información sea decodificada pudiera utilizar un Json Web Encryption para proteger los datos del payload.
Un ejemplo puede ser cuando se tienen muchas aplicaciones apuntando al mismo authorization server
Usaría JWT cuando necesito escalabilidad y desacoplamiento, por ejemplo en SPAs, APIs REST, microservicios o integraciones B2B, donde el backend debe ser stateless, validar tokens rápidamente y no depender de una sesión centralizada. Un buen ejemplo es un frontend Angular consumiendo una API Spring Boot o varios microservicios validando el mismo token emitido por Keycloak.
Optaría por alternativas como sesiones tradicionales cuando el sistema es monolítico, server-side rendered, con control total del backend y sin necesidad de compartir identidad entre múltiples servicios. Aquí las sesiones son más simples, permiten revocación inmediata y reducen riesgos si no se gestionan bien los tokens en el cliente.
Quizás no deberíamos utilizar un JWT cuando tenemos la necesidad de un claim específico que sea protegido. Caso hipotético con un ser en un servidor de autenticación de una entidad gubernamental protegida, CIA, FBI, la identificación del usuario no debería ir en el payload ni quizás el nombre real.
