Pular para o conteúdo

Verificador de JWKS

JWKS Verifier

Busca um endpoint JWKS, escolhe a chave pelo kid e verifica a assinatura e as claims padrão de um token.

Verifica um token contra o JWKS publicado por um emissor — busque por URL ou cole —, escolhendo a chave pelo `kid`, checando a assinatura e depois checando `exp`, `nbf` e, se você os nomear, `iss` e `aud`. O token nunca é enviado; só a URL do JWKS é buscada.

🔒 Roda inteiramente no seu navegadorjwtjwksauthverify

O token não sai desta aba.

A conferência da assinatura é feita pelo WebCrypto do navegador e esta página não tem lado servidor. A única requisição de rede é um GET para a URL do JWKS que você digitar, e essa requisição não leva nada além da URL — não leva o token.

Token

O prefixo Bearer é tirado para você.

Chaves públicas (JWKS)

Origem das chaves

O navegador faz um GET direto. O token não é enviado.

O `jwks_uri` do /.well-known/openid-configuration do emissor é este endereço.

Valores esperados (opcional)

Margem de desvio do relógio

Deixe um vazio e aquele claim não é conferido. exp e nbf são sempre conferidos.

O que é conferido

  • · RS256/384/512, PS256/384/512, ES256/384/512 e EdDSA (Ed25519) são verificados com o WebCrypto (RFC 7518 §3, RFC 8037). HS* usa um segredo compartilhado e não dá para conferir contra um JWKS: disso cuida o decodificador de JWT com o segredo. ES256K e Ed448 não existem no WebCrypto de nenhum navegador.
  • · A chave é escolhida pelo kid do cabeçalho do token (RFC 7515 §4.1.4). Durante uma rotação de chaves um JWKS tem várias, então um kid que não bate é reportado assim mesmo.
  • · exp e nbf são conferidos com a margem de desvio; iss e aud só quando você dá um valor esperado (RFC 7519 §4.1). alg: none é sempre recusado.

Como usar

  1. Cole o token

    Seu `alg`, `kid` e emissor são lidos na hora, que é o que te diz de qual JWKS você precisa.

  2. Busque ou cole o conjunto de chaves

    O `/.well-known/openid-configuration` do emissor nomeia seu `jwks_uri`. Google, Microsoft e Apple têm botões de atalho; qualquer outro você digita ou cola.

  3. Preencha o que você espera

    Um `iss` e um `aud` que você deixar vazios não são checados de forma nenhuma — que é como um token feito para outra audiência acaba aceito em sistemas reais. A tolerância de desvio de relógio cobre servidores que discordam em um minuto.

  4. Leia o veredicto e a tabela de claims

    O banner diz aceitar ou não aceitar; a tabela abaixo diz qual checagem produziu essa resposta e qual chave foi selecionada.

Perguntas frequentes

A busca falhou com um erro de CORS.

Um endpoint JWKS precisa enviar cabeçalhos CORS para um navegador conseguir lê-lo. Google, Microsoft e Apple enviam; muitos emissores auto-hospedados não. Busque você mesmo com curl e cole o JSON: a verificação é idêntica nos dois casos.

Ele diz que nenhuma chave casa com o kid.

Normalmente uma rotação de chaves: o token foi assinado antes de o emissor rotacionar, e o JWKS agora só tem as chaves mais novas. Também pode significar que o token veio de um emissor diferente do JWKS que você buscou.

Por que `alg: none` é sempre recusado?

Porque aceitá-lo é a vulnerabilidade clássica do JWT: um atacante reescreve o cabeçalho, tira a assinatura, e uma biblioteca que confia no cabeçalho deixa o token passar. Não há uso legítimo para ele em um caminho de verificação.

Ele consegue checar um token HS256?

Aqui não: HS* é um segredo compartilhado e um JWKS publica chaves públicas. Use o decodificador de JWT, que aceita um segredo. Um emissor que publicasse chaves HMAC em um JWKS estaria publicando a capacidade de emitir tokens.

Pode receber de

Em seguida

Estas aceitam o que esta ferramenta produz, então o resultado pode ir direto.