# JWT: qué es un token y cómo usarlo con seguridad > Un JWT permite transportar afirmaciones firmadas entre sistemas, pero la firma no cifra el contenido. La seguridad depende de validar algoritmo, emisor, audiencia, vencimiento y contexto. - URL canónica: https://visteesto.com/nota/jwt-que-es-token-como-usarlo-seguridad - Autor: [Martin Rodriguez](https://visteesto.com/autor/martin-rodriguez) - Publicado: 2026-09-26T15:00:00.000Z - Actualizado: 2026-09-26T15:00:00.000Z - Sección: Tecnología - Tema: jwt-tokens-seguridad-apis - Idioma: es - Consulta principal: qué es JWT y cómo usarlo con seguridad ## Resumen verificable - Un JWT contiene un encabezado, un payload de claims y una firma separados por puntos. ([evidencia](https://www.rfc-editor.org/rfc/rfc7519.html)) - La firma de un JWT protege integridad y autenticidad, pero no cifra el contenido del payload. ([evidencia](https://www.rfc-editor.org/rfc/rfc7519.html)) - La validación debe fijar algoritmos permitidos y evitar cambios de algoritmo controlados por el token. ([evidencia](https://www.rfc-editor.org/rfc/rfc8725.html)) - Un bearer token enviado en una cabecera autoriza a quien lo posee mientras siga siendo válido. ([evidencia](https://www.rfc-editor.org/rfc/rfc6750.html)) ## Aporte editorial de VisteEsto VisteEsto organiza los RFC en una ruta práctica que separa formato, validación de claims, política de algoritmos, revocación y pruebas de seguridad. ## Qué es un JWT Un JSON Web Token (JWT) es una representación compacta de afirmaciones que un sistema puede transportar entre dos partes. El formato habitual tiene tres segmentos separados por puntos: un encabezado, un conjunto de datos llamado payload y una firma. Cada segmento se codifica para poder viajar dentro de una URL o una cabecera HTTP. El encabezado suele indicar el tipo de token y el algoritmo de firma. El payload contiene claims como el emisor (`iss`), la audiencia (`aud`), el sujeto (`sub`) y la fecha de vencimiento (`exp`). La firma permite comprobar que el token fue emitido por quien controla la clave correspondiente y que el contenido no cambió después de firmarse. La firma no vuelve secreto al payload. Cualquiera que reciba un JWT puede decodificar sus dos primeros segmentos, por lo que no deben incluirse contraseñas, datos personales innecesarios ni secretos. Si el contenido debe permanecer confidencial, hace falta cifrado y una estrategia distinta, no sólo una firma JWT. ## Cómo se usa en una API Después de autenticar a una persona o servicio, el emisor firma un token con una clave. El cliente lo envía en cada petición protegida, normalmente con la cabecera `Authorization: Bearer `. El servidor verifica la firma y las claims antes de decidir si la operación está autorizada. Un token válido sólo demuestra las afirmaciones que el servidor decidió confiar; no reemplaza los permisos de cada recurso. El servidor debe comprobar que el token no esté vencido, que el emisor y la audiencia sean los esperados y que el sujeto corresponda con una identidad válida. También debe rechazar tokens malformados, con una firma ausente o emitidos para otro servicio. La comprobación debe ocurrir antes de usar cualquier dato del payload para construir consultas o conceder acceso. El formato puede ser útil cuando varios servicios necesitan verificar una identidad sin consultar una sesión central en cada petición. Esa comodidad tiene un costo: revocar un token emitido exige una expiración corta, una lista de revocación o un mecanismo de introspección. Guardar muchos permisos dentro del token tampoco evita que el servidor tenga que revisar el estado actual del usuario. ## Qué significa validar la firma Validar un JWT no consiste en aceptar cualquier algoritmo que el token declare. La aplicación debe elegir una política de algoritmos permitidos y asociarla con el tipo de clave correcto. RFC 8725 recomienda evitar configuraciones que permitan cambiar de algoritmo o confundir una clave pública con una clave HMAC. La biblioteca debe recibir esa política desde el servidor, no desde el encabezado controlado por el cliente. Además de la firma, conviene exigir los claims necesarios para el servicio. `exp` limita la vigencia, `nbf` evita aceptar un token antes de tiempo, `iss` identifica al emisor y `aud` limita el servicio al que está dirigido. Una validación que sólo comprueba que la firma matemática coincide puede aceptar un token auténtico pero destinado a otra aplicación. Las claves de firma deben rotarse y distribuirse por un canal controlado. El identificador de clave (`kid`) puede ayudar a elegir una clave durante una rotación, pero no debe permitir que el cliente fuerce la lectura de una URL o un archivo arbitrario. Registrá los errores de validación sin guardar el token completo en logs, porque un bearer token funciona como una credencial mientras siga vigente. ## Checklist antes de elegir JWT Usá JWT cuando la portabilidad de las afirmaciones firmadas resuelva un problema real entre servicios. Para una aplicación web con un único backend, una sesión del lado del servidor puede ser más sencilla de revocar y de limitar. El token no aporta seguridad por sí mismo: sólo formaliza cómo se transporta una identidad y qué controles se aplican al recibirla. Antes de llevarlo a producción, definí una expiración corta, renovación y la forma de revocar sesiones comprometidas. Limitá los claims a lo que el servicio necesita, aceptá sólo algoritmos explícitos, comprobá `iss`, `aud`, `exp` y `nbf`, y protegé la clave privada. Si el token viaja por una cookie, configurá `Secure`, `HttpOnly` y una política `SameSite` adecuada; si viaja en una cabecera, protegé el almacenamiento del cliente contra filtraciones. Probá tokens vencidos, tokens con otra audiencia, cambios de algoritmo, firmas alteradas, claves rotadas y reenvíos a un endpoint diferente. Esa matriz muestra si la implementación verifica el contexto completo o sólo decodifica texto. La documentación de RFC 7519 y RFC 8725 sirve como base para la sintaxis y las prácticas, mientras que cada biblioteca debe revisarse por su versión y configuración concreta. ## Fuentes consultadas - Fuente primaria: [RFC 7519: JSON Web Token (JWT)](https://www.rfc-editor.org/rfc/rfc7519.html) - Fuente primaria: [RFC 8725: JSON Web Token Best Current Practices](https://www.rfc-editor.org/rfc/rfc8725.html) - Fuente primaria: [RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://www.rfc-editor.org/rfc/rfc6750.html) ## Imágenes y licencias - Token JWT dividido en claims y firma junto a un escudo de validación. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/jwt-que-es-token-como-usarlo-seguridad). - Servidor que valida issuer audience y expiración de un JWT. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/jwt-que-es-token-como-usarlo-seguridad). - Rotación de claves que mantiene la validación de tokens JWT. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/jwt-que-es-token-como-usarlo-seguridad). ## Cómo citar Citar título, autor, fecha de publicación o actualización y la URL canónica. Las afirmaciones centrales incluyen su evidencia directa arriba. Esta versión Markdown es una representación accesible; la nota HTML canónica es la fuente editorial de referencia.