Revisar un JWKS antes de publicarlo
Antes de poner en línea /.well-known/jwks.json, comprueba que ninguna clave contiene d o k y que cada una lleva un kid único.
Seguridad y privacidad
Inspector JWK / JWKS
Pega una JWK o un JWKS para obtener una tabla por clave (kid, kty, alg, use, key_ops, huella SHA-256 RFC 7638) y avisos: kty o kid ausente, kid duplicado, material de clave privada publicado por error.
- Portapapeles
Datos no enviados
Advertencias
Claves
| # | kid | kty | alg | use | key_ops | Naturaleza | Huella SHA-256 (RFC 7638) |
|---|
Informe JSON
¿Te ha resultado útil esta herramienta?
¿Cómo funciona esta herramienta?
El inspector JWK / JWKS hace legible un conjunto de claves JSON Web Key, como el que publica un proveedor OpenID Connect en su jwks_uri. Está pensado para desarrolladores y equipos de seguridad que publican o consumen un JWKS y quieren ver de un vistazo qué claves contiene, cómo se identifican y si se ha incluido por error algún dato privado.
Una JWK (RFC 7517) describe una clave en JSON: kty indica la familia (RSA, EC, oct), kid el identificador, alg el algoritmo previsto, use el uso (sig para firma, enc para cifrado) y key_ops las operaciones permitidas. Un JWKS es simplemente un objeto {"keys":[…]} que agrupa varias. La herramienta acepta ambas formas, muestra una fila por clave y resume el número de claves, los tipos presentes y los kid distintos. También calcula la huella RFC 7638 de cada clave: el hash SHA-256, codificado en Base64URL, de un JSON canónico que solo contiene los miembros obligatorios en orden alfabético, es decir e, kty y n para RSA, crv, kty, x e y para EC, y k y kty para una clave simétrica.
Los avisos apuntan a errores reales de publicación: kty ausente (la clave no se puede usar), kid ausente cuando el conjunto tiene varias claves (el verificador no sabe cuál usar), kid duplicado y, sobre todo, presencia de material privado. En RSA, los miembros d, p, q, dp, dq y qi son la clave privada; en EC, es d; en una clave simétrica oct, el miembro k es el propio secreto. Un JWKS público solo debe contener claves públicas; si no, cualquiera puede firmar tokens en tu nombre. El resultado se puede exportar en JSON.
Cómo utilizar esta herramienta
Pega la JWK o el JWKS
Pega una clave sola {"kty":…} o un conjunto completo {"keys":[…]}, por ejemplo copiado desde el jwks_uri de tu proveedor.
Lee la tabla de claves
Para cada clave, revisa kid, kty, alg, use, key_ops y la huella SHA-256 RFC 7638, además del resumen con el número de claves, los tipos y los kid distintos.
Atiende los avisos
Corrige los kty o kid ausentes y los kid duplicados, elimina cualquier dato privado y exporta el resultado en JSON si lo necesitas.
Casos de uso
Seguir una rotación de claves
Pega el JWKS de tu proveedor (Auth0, Keycloak, Entra ID, Google) durante una rotación para ver la clave antigua y la nueva lado a lado, con su kid y su huella.
Encontrar la clave que firmó un token
Compara el kid de la cabecera de un JWT con los del JWKS para identificar la clave esperada y comprueba después la firma con el verificador JWT.
Consejos y buenas prácticas
- Un aviso de clave privada en un JWKS ya publicado obliga a revocar y sustituir la clave: quitarla del archivo no basta, porque ya pueden haberla copiado.
- Evita un kid basado en un contador o en una fecha previsible si puedes usar la huella RFC 7638: es estable e idéntica sea cual sea el formato del JSON.
- Una clave oct (simétrica) nunca debe estar en un JWKS público: los secretos HMAC se comparten por otro canal, mediante un gestor de secretos.
Preguntas frecuentes
¿Qué diferencia hay entre una JWK y un JWKS?
Una JWK es una sola clave representada en JSON, con campos como kty, n, e o x e y. Un JWKS (JSON Web Key Set) es un objeto {"keys":[…]} que contiene una lista de JWK, normalmente publicado por un servidor de autorización para que los clientes verifiquen sus tokens.
¿Qué es la huella (thumbprint) de una JWK?
Es un identificador calculado según la RFC 7638: el SHA-256 de un JSON canónico que solo contiene los miembros obligatorios de la clave pública, codificado en Base64URL. Dos representaciones de la misma clave dan siempre la misma huella, y la huella de una clave privada es la de su clave pública. Muchos proveedores la usan como kid.
¿Es obligatorio el kid en un JWKS?
La RFC 7517 lo deja como opcional, pero en cuanto un JWKS tiene varias claves se vuelve imprescindible: el kid de la cabecera del JWT es lo que permite elegir la clave correcta. Sin él, el verificador tiene que probar todas las claves, algo que muchas bibliotecas rechazan.
¿Cómo saber si una JWK contiene una clave privada?
Una JWK RSA es privada si contiene d (y a menudo p, q, dp, dq, qi); una JWK EC es privada si contiene d; una clave oct siempre guarda el secreto en k. La herramienta señala estos miembros. Una clave pública RSA solo contiene kty, n y e, más metadatos opcionales.
¿Qué significan kty RSA, EC y oct?
RSA es una clave RSA que se usa por ejemplo con RS256 o PS256; EC es una clave de curva elíptica (P-256, P-384, P-521) que se usa con ES256, ES384 o ES512; oct es una clave simétrica, una secuencia secreta de bytes que se usa con HS256 o para cifrado AES.
¿Qué diferencia hay entre use y key_ops?
use indica el uso general de la clave: sig para firma, enc para cifrado. key_ops enumera con precisión las operaciones permitidas, como verify, sign, encrypt o wrapKey. La RFC 7517 recomienda no usar ambos a la vez o, si se hace, que sean coherentes.
Herramientas relacionadas
Continúa con estas herramientas
Herramientas similares o complementarias a esta.
Funciona bien con
Verifica la firma de un JWT con un secreto HMAC o una clave pública JWK, JWKS o PEM, y comprueba exp, nbf, iss y aud.
Seguridad y privacidadUsar esta herramienta
Decodifica un JWT para leer su cabecera, su payload, sus claims y sus fechas de expiración.
Seguridad y privacidadDestacadaUsar esta herramienta
Genera un code_verifier PKCE, su code_challenge S256 y un state para tu petición de autorización OAuth.
Seguridad y privacidadNuevaUsar esta herramienta
También te puede interesar
GuíaBuenas prácticasIntermedio
OAuth 2.0, PKCE, JWT, JWK y JWKS: entender sus funciones
Comprende cómo encajan OAuth 2.0, PKCE, JWT, JWK y JWKS: autorización, tokens, claves públicas y verificación.
23 de septiembre de 20262 min
GuíaBuenas prácticasPrincipiante
Content Security Policy (CSP): reducir riesgos XSS y cargas no deseadas
Aprende a implantar una CSP de forma progresiva, sus directivas principales, Report-Only, nonces y errores frecuentes.
29 de agosto de 20261 min