Saltar al contenido

Verificador de JWKS

JWKS Verifier

Descarga un endpoint JWKS, elige la clave por su kid y verifica la firma del token y sus reclamaciones estándar.

Verifica un token contra el JWKS publicado por un emisor —descárgalo por URL o pégalo—, eligiendo la clave por `kid`, comprobando la firma, y luego comprobando `exp`, `nbf` y, si los nombras, `iss` y `aud`. El token nunca se envía; solo se descarga la URL del JWKS.

🔒 Se ejecuta por completo en tu navegadorjwtjwksauthverify

El token no sale de esta pestaña.

La comprobación de la firma la hace el WebCrypto del navegador y esta página no tiene lado servidor. La única petición de red es un GET a la URL del JWKS que escribas, y esa petición no lleva más que la URL — no el token.

Token

El prefijo Bearer se quita por ti.

Claves públicas (JWKS)

Origen de las claves

El navegador hace un GET directo. El token no se envía.

El `jwks_uri` del /.well-known/openid-configuration del emisor es esta dirección.

Valores esperados (opcional)

Margen de desfase del reloj

Deja uno vacío y ese claim no se comprueba. exp y nbf se comprueban siempre.

Qué se comprueba

  • · RS256/384/512, PS256/384/512, ES256/384/512 y EdDSA (Ed25519) se verifican con WebCrypto (RFC 7518 §3, RFC 8037). HS* usa un secreto compartido y no se puede comprobar contra un JWKS: de eso se encarga el decodificador de JWT con el secreto. ES256K y Ed448 no están en el WebCrypto de ningún navegador.
  • · La clave se elige por el kid de la cabecera del token (RFC 7515 §4.1.4). Durante una rotación de claves un JWKS lleva varias, así que un kid que no coincide se informa como tal.
  • · exp y nbf se comprueban con el margen de desfase; iss y aud solo cuando das un valor esperado (RFC 7519 §4.1). alg: none se rechaza siempre.

Cómo se usa

  1. Pega el token

    Su `alg`, `kid` y emisor se leen al instante, que es lo que te dice qué JWKS necesitas.

  2. Descarga o pega el conjunto de claves

    El `/.well-known/openid-configuration` del emisor nombra su `jwks_uri`. Google, Microsoft y Apple tienen botones de atajo; cualquier otro lo escribes o lo pegas.

  3. Rellena lo que esperas

    Un `iss` y un `aud` que dejes vacíos no se comprueban en absoluto, que es como un token pensado para otra audiencia acaba aceptándose en sistemas reales. El margen de desfase de reloj cubre servidores que discrepan en un minuto.

  4. Lee el veredicto y la tabla de claims

    El banner dice aceptar o no aceptar; la tabla de debajo dice qué comprobación produjo esa respuesta y qué clave se seleccionó.

Preguntas frecuentes

La descarga falló con un error de CORS.

Un endpoint JWKS tiene que enviar cabeceras CORS para que un navegador pueda leerlo. Google, Microsoft y Apple lo hacen; muchos emisores autoalojados no. Descárgalo tú mismo con curl y pega el JSON: la verificación es idéntica en ambos casos.

Dice que ninguna clave coincide con el kid.

Normalmente una rotación de claves: el token se firmó antes de que el emisor rotara, y el JWKS ahora solo contiene las claves más nuevas. También puede significar que el token vino de un emisor distinto del JWKS que descargaste.

¿Por qué `alg: none` se rechaza siempre?

Porque aceptarlo es la vulnerabilidad clásica de JWT: un atacante reescribe la cabecera, quita la firma, y una biblioteca que confía en la cabecera deja pasar el token. No tiene ningún uso legítimo en una ruta de verificación.

¿Puede comprobar un token HS256?

Aquí no: HS* es un secreto compartido y un JWKS publica claves públicas. Usa el decodificador de JWT, que acepta un secreto. Un emisor que publicara claves HMAC en un JWKS estaría publicando la capacidad de acuñar tokens.

Puede recibir de

Después

Estas aceptan lo que produce esta herramienta, así que el resultado puede pasar directamente.