Herramientas de desarrollo · JWT decodificador
Por qué son importantes los tokens de acceso de corta duración: los JWT no se pueden revocar una vez emitidos
· Por qué es importante
jwt autenticación seguridad
Un token autónomo es válido hasta que caduque, pase lo que pase en el medio. Esta publicación explica el problema de la revocación, las mitigaciones disponibles y por qué exp es el reclamo más importante que establece.
Cierre de sesión que no cierra la sesión: el token que sigue funcionando después de finalizar la sesión
Cerrar sesión puede eliminar la copia local de un navegador, mientras que un token autónomo emitido previamente sigue siendo aceptable para un verificador que solo verifica firmas y afirmaciones. La experiencia del usuario dice "cerrado sesión", pero otro titular puede conservar la misma credencial compacta hasta que un límite de política lo impida.
Esto no es algo que un decodificador pueda resolver. ToolAcre puede mostrar un valor `exp` y llamarlo caducado en relación con el reloj del navegador, pero no tiene almacenamiento de sesiones, lista de denegados ni conexión de emisor. El comportamiento de revocación pertenece a la arquitectura que emite y consume credenciales.
Verificación sin estado y su precio: no tener una lista central significa que no hay un interruptor de apagado central
La verificación sin estado permite que un servidor de recursos evalúe material criptográfico y reclamos sin consultar un registro de sesión central para cada solicitud. Eliminar esa búsqueda también elimina un cambio natural por sesión a menos que se agregue otro mecanismo con estado. El comercio es arquitectónico, no una propiedad visible solo en JSON.
Un token puede contener `jti`, pero el identificador no tiene efecto de revocación hasta que un verificador consulte un almacén o regla confiable. Del mismo modo, una firma puede seguir siendo matemáticamente válida después de que se deshabilite una cuenta. La aceptación de la solicitud requiere una política actual, no solo una prueba de que algunos bytes históricos firmados clave.
El diseño de vencimiento y actualización puede limitar la exposición, pero este repositorio no define una vida útil estándar
Los sistemas a menudo combinan una credencial de acceso limitada con un mecanismo de actualización independiente, pero este repositorio no define una vida útil universal ni afirma que una duración sea razonable. Las limitaciones de riesgo, experiencia del usuario, detección e infraestructura difieren, por lo que este artículo no inventa una guía sobre la vida útil del token.
El principio es más limitado: un límite de vencimiento puede limitar cuánto tiempo un token de acceso robado sigue siendo útil si el verificador aplica un `exp` autenticado. El procesamiento de actualización puede luego consultar más estados antes de emitir otra credencial. ToolAcre solo muestra los reclamos; no realiza ni aplicación ni actualización.
Listas de denegados por jti: reintroducción del estado para los casos que necesitan una revocación inmediata
Una lista de denegados codificada por `jti` puede reintroducir un punto de decisión inmediato para los tokens seleccionados. Eso requiere un identificador único, una ruta de inserción confiable, disponibilidad de almacenamiento y una política de búsqueda de verificadores. Simplemente decodificar un `jti` no muestra unicidad ni prueba que una tienda lo contenga.
El mismo estado puede admitir la invalidación de toda la cuenta o de una sesión específica, según el diseño. También restaura las dependencias operativas que la verificación sin estado evitó. Evalúe la falla, la retención y la propagación de la caché de manera explícita en lugar de presentar una lista de denegados como una opción gratuita.
Introspección y rotación de claves: preguntar al emisor o invalidar todo a la vez
La introspección solicita a una autoridad el estado actual del token, convirtiendo la aceptación en una decisión en línea. La rotación de claves puede detener la verificación de las claves eliminadas, pero puede invalidar muchos tokens a la vez y no es un sustituto preciso de la revocación de sesión. Estos mecanismos resuelven diferentes problemas operativos.
ToolAcre no conoce su estado actual. Un emisor decodificado, un identificador de clave o un vencimiento pueden ayudar a localizar registros relevantes, pero el panel nunca contacta a un emisor y nunca verifica una firma. Utilice la telemetría de servicio autorizada para saber si un token está activo, revocado o rechazado.
Ejemplo resuelto: calcular el intervalo declarado sin juzgar si es razonable
Para un ejemplo controlado, reste el `iat` numérico de `exp` para calcular el intervalo reclamado por la carga útil. Si `iat` es 1,717,243,200 y `exp` es 1,717,246,800, la diferencia es 3,600 segundos. ToolAcre también muestra cada valor como un instante ISO.
La aritmética no juzga el intervalo. No puede probar que ninguno de los reclamos haya sido emitido por la parte esperada y el repositorio no proporciona una vida útil recomendada. Compare los valores autenticados con su política documentada solo después de la verificación, luego pruebe cómo el estado de cierre de sesión y revocación afecta las solicitudes reales.
Lo que esto no cubre: actualizar el almacenamiento y la rotación de tokens, que son su propio problema de diseño.
El almacenamiento de tokens de actualización, la rotación y la detección de reproducción son temas de diseño separados. Un token de actualización puede ser opaco, puede tener un manejo diferente y no debe enviarse a una API de recursos simplemente porque se rechaza un token de acceso. Este decodificador tiene la forma específica de una entrada tipo JWS de tres partes.
No pegue las credenciales de actualización en él. Si un token de actualización es opaco, es posible que no haya nada útil que decodificar; si está estructurada, la divulgación aún crea riesgo de credencial. Diagnostique los flujos de emisión utilizando las herramientas y los registros confiables del proveedor.
La caducidad es una palanca entre la verificación, el estado de revocación y el diseño de credenciales.
La caducidad es útil, pero no es una estrategia de revocación completa ni un veredicto de descodificación. El sistema consumidor debe autenticar el token, hacer cumplir la política de tiempo y audiencia y consultar cualquier estado de revocación que requiera su arquitectura. Cada mecanismo tiene consecuencias operativas y de disponibilidad.
Utilice ToolAcre solo para observar los valores en un token seguro. Puede responder "¿qué intervalo reclama esta carga útil?" No puede responder “¿debería aceptarse esta solicitud ahora?” o “¿se revoca esta sesión?” Esas preguntas pertenecen a servicios confiables.