Herramientas de desarrollo · JWT decodificador
Los siete reclamos registrados JWT: iss, sub, aud, exp, nbf, iat y jti
· Antecedentes
jwt formatos de datos autenticación
RFC 7519 reserva siete nombres de reclamos con significados y tipos definidos. Esta publicación explica cada uno, los tipos StringOrURI y NumericDate detrás de ellos, y cómo coexisten los reclamos registrados, públicos y privados.
¿Qué nombres de reclamos debo usar? — la pregunta de diseño que responde el registro
La elección de los nombres de las reclamaciones es en parte una decisión de interoperabilidad. La reutilización de un nombre registrado proporciona a los lectores y bibliotecas un significado establecido, mientras que los nombres específicos de la aplicación requieren documentación local. ToolAcre reconoce siete nombres principales en su tabla de descripción y deja visibles otras afirmaciones sin asignar semántica.
Un nombre familiar no es automáticamente confiable. El decodificador lee cualquier objeto que contenga el token y nunca verifica su firma. El vocabulario registrado ayuda a los humanos a clasificar datos; sólo un verificador confiable puede establecer que un emisor proporcionó el valor protegido.
iss y sub se muestran como cadenas; esta implementación no aplica la sintaxis StringOrURI
`iss` identifica quién afirma que el token lo emitió y `sub` identifica de quién o de qué se trata. ToolAcre describe ambos y muestra sus valores, pero su implementación no valida una gramática StringOrURI ni compara ninguno de los campos con la configuración del servicio.
Un verificador debe vincular al emisor esperado con material clave confiable e interpretar el asunto bajo el espacio de nombres de ese emisor. Copiar una cadena de emisor conocida en una carga útil fabricada hace que el decodificador parezca convincente sin establecer el origen. Utilice estos campos sólo después de la verificación criptográfica.
aud: los destinatarios previstos, como una cadena o una matriz
`aud` describe los destinatarios previstos y puede representarse como un valor o una lista según las reglas de token aplicables. La tabla de reclamos genérica de ToolAcre conserva matrices como texto JSON pero no decide si el servicio actual aparece en ellas.
La audiencia es contextual. El mismo token autenticado puede ser apropiado para una API e incorrecto para otra. Un servidor de recursos necesita un identificador esperado en una configuración confiable y debe rechazar una discrepancia en lugar de permitir que el token defina dónde debe aceptarse.
exp, nbf e iat: las tres afirmaciones de NumericDate que vinculan un token en el tiempo
`exp`, `nbf` y `iat` son notificaciones de NumericDate. ToolAcre trata los números finitos como segundos desde la época, los multiplica por 1,000 para mostrar la fecha y etiqueta la caducidad o no antes en relación con el reloj del navegador. No define margen de maniobra ni exige la aceptación del servidor.
Una caducidad marca un límite final reclamado, no una prueba de que el token alguna vez haya sido válido. El no antes marca un límite de inicio reclamado y el emitido en registra un tiempo de creación reclamado. Cada uno puede falsificarse en una carga útil, por lo que la aritmética del tiempo debe seguir a la verificación de firmas en un flujo confiable.
jti: un identificador único para la detección de reproducciones y listas de denegados
`jti` es un identificador de token. Los sistemas pueden utilizar un identificador autenticado y generado adecuadamente para el seguimiento de la reproducción o el estado de revocación, pero la reclamación por sí sola no proporciona ninguna de las dos propiedades. ToolAcre lo describe como una identificación de token para la detección de repetición y muestra su valor exacto.
La unicidad, el almacenamiento y el comportamiento de búsqueda pertenecen a la arquitectura del emisor y del verificador. Un decodificador no puede determinar si otro token reutilizó el identificador o si lo contiene una lista de denegados. Trátelo como un valor de correlación candidato hasta que el sistema confiable circundante proporcione evidencia.
Descripciones registradas y reclamos específicos de la aplicación en la pantalla ToolAcre
La implementación distingue los nombres registrados solo mediante texto explicativo. Cada propiedad de carga útil todavía es devuelta por `listClaims`; Los nombres desconocidos reciben una descripción nula y la interfaz de usuario los etiqueta como específicos de la aplicación. No consulta un registro público ni evita colisiones de nombres privados.
Ese límite evita afirmar más de lo que la fuente demuestra. Los equipos deben documentar sus reclamos privados y elegir nombres resistentes a colisiones cuando la interoperabilidad sea importante. La ausencia de una descripción en el decodificador significa "no en esta tabla local de siete nombres", no "no válido" o "seguro de ignorar".
Ejemplo resuelto: leer una carga útil realista y clasificar cada reclamo
Considere `{"iss":"https://issuer.example","sub":"user-7","aud":["orders"],"exp":1717246800,"nbf":1717243100,"iat":1717243200,"jti":"demo-9","tenant":"north"}`. ToolAcre describe los siete campos registrados y etiquetas `tenant` específicas de la aplicación mientras formatea las tres veces numéricas.
Esta clasificación ayuda a revisar el diseño de la carga útil. No autentica la URL, el asunto, la audiencia, las fechas, el identificador o el inquilino. Una ficha falsificada puede reproducir el objeto exactamente. Introduzca solo reclamaciones verificadas en la lógica de autorización y luego aplique los valores esperados del servicio consumidor.
Conclusión: utilice los nombres registrados cuando encajen: el decodificador ToolAcre JWT muestra la carga útil para que pueda ver qué reclamaciones establece un emisor real
Utilice nombres registrados cuando sus significados definidos encajen, porque el vocabulario reconocible reduce la traducción innecesaria. Mantenga los campos privados documentados y mínimos. No sobrecargue `sub`, `aud` o un reclamo de tiempo con un significado local diferente simplemente porque el código posterior ya analiza esa clave.
ToolAcre puede mostrar qué nombres lleva un token seguro y cómo se representan sus reclamos numéricos. No puede certificar ningún valor. El resultado útil de la decodificación es un inventario para revisión; el resultado útil de la verificación y la política es una decisión, y ambas permanecen separadas.