Herramientas de desarrollo · JWT decodificador
Verificaciones de audiencia y emisor: evitar que un JWT se reproduzca en otro lugar
· Por qué es importante
jwt autenticación seguridad
Un token emitido para un servicio se puede presentar a otro que comparta el mismo emisor. Esta publicación explica cómo los controles aud e iss detienen esto y cómo leer ambos reclamos en un token.
El servicio B acepta un token destinado al servicio A: la reproducción entre servicios que una firma válida no impide
Una firma puede ser válida para un token que se emitió para un servicio diferente. Si varias API confían en la misma plataforma de identidad pero ignoran el contexto del destinatario, una credencial destinada al servicio A puede reproducirse en el servicio B. La integridad criptográfica por sí sola no determina quién debe consumirla.
ToolAcre puede revelar `iss` y `aud` para que un desarrollador pueda detectar una discrepancia obvia. Esas cadenas permanecen sin verificar hasta que la firma se realiza correctamente y la herramienta del navegador nunca realiza esa verificación. El servidor de recursos real debe hacer cumplir tanto su relación con el emisor como con su público objetivo.
iss: vincular un token al emisor en el que confía su servicio y por qué una coincidencia de cadena no es suficiente sin la vinculación de claves
`iss` identifica la entidad que, según la carga útil, emitió el token. Un verificador necesita un emisor esperado exacto bajo su propia configuración y debe vincular esa identidad a la relación clave-descubrimiento correcta. Comparar texto sin el enlace criptográfico deja espacio para que un atacante copie la cadena esperada.
El decodificador describe `iss` como "quién creó el token", pero ese es el significado registrado, no un hallazgo sobre un valor pegado. El texto legible del emisor es una prueba útil para la configuración de depuración. No puede seleccionar una fuente de clave arbitraria ni autenticarse.
aud: una cadena o matriz que nombra a los destinatarios previstos y la regla que un verificador debe encontrar en ella
`aud` nombra los destinatarios previstos y puede aparecer como una cadena o una colección. La política del servidor de recursos debe encontrarse en el valor autenticado utilizando las reglas de comparación exactas requeridas por su perfil. No debería aceptar un token simplemente porque se incluye algún otro servicio conocido.
ToolAcre lleva matrices como texto JSON en su tabla de reclamos, preservando su estructura visible para inspección. No conoce el identificador de la API actual y no puede decidir una coincidencia. Esa ausencia deliberada impide que un decodificador genérico invente un contexto de autorización que no posee.
azp y alcance: las afirmaciones de OpenID Connect y OAuth que refinan quién puede usar el token y para qué
`azp` y `scope` pueden agregar contexto sobre una parte autorizada y permisos solicitados en los perfiles que los definen. No reemplazan los controles de audiencia, emisor o firma. Un nombre de ámbito es una afirmación, no una concesión de permiso hasta que el servidor de recursos asigne un valor autenticado a su propia política.
El decodificador actual los trata como reclamos específicos de la aplicación porque su tabla de descripción registrada cubre siete nombres principales. Muestra sus valores pero no proporciona semántica de OpenID Connect u OAuth. Consulta el perfil aplicable y el contrato del proveedor antes de utilizarlos en una decisión.
El patrón del diputado confundido: cómo un token legítimo se convierte en un ataque cuando no se controla a las audiencias
Un diputado confundido utiliza la autoridad legítima en un contexto no deseado. Un token aceptado por el servicio equivocado puede desencadenar exactamente ese patrón incluso cuando nadie falsificó la firma. Las verificaciones de audiencia limitan dónde se pueden aplicar las afirmaciones autenticadas, mientras que las verificaciones del emisor limitan qué afirmaciones considera el servicio.
Esta es la razón por la cual un indicador general de "firma válida" aún sería insuficiente. La autorización depende del destinatario y de la operación. ToolAcre evita esa ambigüedad por completo al no informar ningún resultado de verificación, dejando que el servicio consumidor combine la criptografía con la política contextual.
Ejemplo resuelto: leer iss y aud de dos tokens en el decodificador ToolAcre JWT y decidir qué servicio debe aceptar cada uno
Cree dos tokens inofensivos cuyas cargas útiles decodificadas difieren solo en `aud`: uno nombra `service-a`, el otro `service-b`; ambos afirman ser del mismo emisor. ToolAcre hace visible la diferencia. Un verificador del servicio A no debería aceptar ninguno de los dos simplemente de esta visualización y debería rechazar la audiencia del servicio B autenticada.
Luego invierta el ejercicio con dos cadenas de emisores. El texto esperado por sí solo no es suficiente a menos que la verificación utilice claves confiables para ese emisor. Estos ejemplos separan la inspección de la aceptación y muestran por qué copiar las afirmaciones correctas en un token fabricado no cambia ninguna política confiable.
Lo que esto no cubre: verificación de firma, que el decodificador nunca realiza; Los cheques aud e iss solo importan después de que se mantenga la firma.
Las comprobaciones de audiencia y emisor son importantes solo después de que la verificación criptográfica establezca que los bytes protegidos corresponden a material de claves confiable. ToolAcre no realiza ninguna de esas verificaciones. Su resultado no puede establecer que un reclamo sobrevivió intacto o que un emisor conocido fue su autor.
Tampoco recupera metadatos, elige claves ni compara destinatarios configurados. Utilice registros y pruebas de backend para demostrar el rechazo de un emisor y una audiencia incorrectos. Una coincidencia visual en un decodificador es una pista de depuración, nunca una prueba de autorización suficiente.
Conclusión: verifique para quién es, no solo quién lo firmó: el decodificador ToolAcre JWT muestra las afirmaciones de aud e iss que necesita comparar
Verifique para quién es el token, no solo el nombre que dice que lo firmó. El flujo robusto autentica bytes protegidos bajo una relación de emisor de confianza independiente, luego requiere una audiencia aceptable y aplica reglas de autorización específicas del servicio.
Utilice ToolAcre para leer valores de prueba seguros y formular la siguiente verificación del lado del servidor. No elija claves de verificación de encabezados o datos de reclamos que no sean de confianza, y no convierta `iss`, `aud`, `azp` o `scope` mostrados en una concesión sin el flujo completamente confiable.