Ir para o conteúdo principal
Bethemesh
Segurança e privacidade

Verificador de assinatura JWT

Valide um JSON Web Token: assinatura HS256/384/512 com o segredo partilhado, RS, PS ou ES 256/384/512 com uma chave pública JWK, JWKS (escolhida pelo kid) ou PEM, seguida do controlo das datas com tolerância de relógio, do emissor e da audiência esperados.

  • Área de transferência

Integrar este widget

Personalize o resultado, verifique a pré-visualização e copie o código.

Pré-visualização

Tipo de código de integração

Código a copiar

Responsivo e redimensionado automaticamente pela Bethemesh.

HS256, HS384, HS512: o segredo partilhado. RS, PS e ES: a chave pública em JWK, JWKS (escolhida pelo kid) ou PEM «BEGIN PUBLIC KEY».

Verificações opcionais

Defina o algoritmo para uma validação semelhante à produção. O modo automático serve sobretudo para inspeção.

Esta ferramenta foi útil?

Como funciona esta ferramenta?

O verificador JWT indica se um token é autêntico e ainda aceitável: controla a sua assinatura criptográfica e depois os claims. Destina-se a programadores back-end, integradores OAuth/OpenID Connect e equipas de segurança que pretendem confirmar que um token foi assinado pela chave certa antes de procurar o erro noutro lado. Para ler apenas o conteúdo de um token, basta o descodificador JWT.

A assinatura de um JWS (RFC 7515) incide sobre a cadeia «cabeçalho.payload» em Base64URL; os algoritmos são definidos pela RFC 7518. Para HS256, HS384 e HS512, a ferramenta recalcula um HMAC com o segredo partilhado e compara-o com a assinatura. Para RS256/384/512 (RSASSA-PKCS1-v1_5), PS256/384/512 (RSASSA-PSS) e ES256/384/512 (ECDSA sobre P-256, P-384 e P-521), verifica a assinatura com a chave pública através da Web Crypto API; em ECDSA, a assinatura JWS é a concatenação direta R‖S, 64 bytes para ES256, e não uma estrutura DER. Um token que declare alg: none é sempre rejeitado.

A chave pública pode ser fornecida de três formas: uma JWK isolada (RFC 7517), um JWKS {"keys":[…]} no qual a ferramenta escolhe a chave cujo kid corresponde ao do cabeçalho, ou um PEM «BEGIN PUBLIC KEY» (SubjectPublicKeyInfo). Para uma validação próxima da produção, selecione um Algoritmo esperado em vez de deixar o modo Automático: assim o token não pode impor outro algoritmo suportado através do seu próprio campo alg. O modo Automático continua útil para inspeção. Depois de validada a assinatura, controla exp e nbf com uma tolerância de relógio ajustável (por exemplo 60 segundos para absorver a diferença entre servidores) e, se os indicar, o emissor iss e a audiência aud esperados. O resultado indica «válido» ou «inválido» com o motivo exato: assinatura incorreta, kid não encontrado, token expirado, ainda não válido, emissor ou audiência inesperados.

Como usar esta ferramenta

  1. Cole o JWT

    Cole o token completo. O algoritmo declarado no cabeçalho determina o tipo de chave esperado: um segredo para HS*, uma chave pública para RS*, PS* e ES*.

  2. Forneça a chave

    Introduza o segredo partilhado ou cole uma chave pública JWK, um JWKS completo ou um PEM PUBLIC KEY. Com um JWKS, a chave é escolhida automaticamente através do kid.

  3. Ajuste os controlos e leia o veredicto

    Ajuste a tolerância de relógio, acrescente se necessário o emissor e a audiência esperados e leia o resultado válido ou inválido com o respetivo motivo.

Casos de uso

Verificar um token Auth0, Keycloak ou Entra ID

Obtenha o JWKS publicado no jwks_uri do seu fornecedor (por exemplo /.well-known/jwks.json), cole-o com o token e confirme que a assinatura RS256 corresponde a uma chave publicada.

Depurar uma rotação de chaves

Após uma rotação, a sua API rejeita tokens: verifique se o kid do cabeçalho ainda existe no JWKS ou se o token foi assinado com uma chave retirada.

Testar um segredo HS256 entre dois serviços

Um microsserviço rejeita os tokens emitidos por outro: teste o segredo partilhado e a audiência esperada para saber se o problema está na chave ou nos claims.

Exemplos

Inspecionar um JWT de teste

Entrada

Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c; algoritmo: HS256; segredo: chave-incorreta

Resultado

Assinatura inválida com esta chave incorreta. Os dados descodificados incluem sub=1234567890 e iat=1516239022, sem campo exp.

Dicas e boas práticas

  • Se só tiver um certificado (BEGIN CERTIFICATE), extraia primeiro a sua chave pública, por exemplo com openssl x509 -pubkey -noout, porque a ferramenta espera um PEM PUBLIC KEY.
  • Um segredo HS256 fornecido em Base64 por um fornecedor tem de ser usado exatamente com os mesmos bytes que serviram para assinar: a cadeia Base64 e a sua versão descodificada não dão a mesma assinatura.
  • Mantenha a tolerância de relógio curta (de algumas dezenas de segundos a poucos minutos): um valor demasiado largo equivale a aceitar tokens expirados.

Fontes e referências

Perguntas frequentes

Qual é a diferença entre descodificar e verificar um JWT?

Descodificar é ler o cabeçalho e o payload codificados em Base64URL, sem qualquer chave. Verificar é recalcular ou controlar a assinatura com o segredo ou a chave pública do emissor e depois validar exp, nbf, iss e aud. Só a verificação prova que o token não foi forjado nem alterado.

Que chave é necessária para verificar um JWT RS256 ou HS256?

HS256 é simétrico: o mesmo segredo assina e verifica. RS256, PS256 e ES256 são assimétricos: o emissor assina com a sua chave privada e o utilizador verifica com a chave pública, normalmente publicada num JWKS. Nunca é necessária a chave privada para verificar.

Para que serve o kid no cabeçalho de um JWT?

O kid (key ID) indica que chave do JWKS assinou o token, o que permite ao emissor publicar várias chaves durante uma rotação. Quando cola um JWKS, a ferramenta seleciona a chave cujo kid corresponde. Se nenhum corresponder, a chave foi provavelmente retirada ou o JWKS não pertence ao emissor certo.

Porque é que a assinatura do meu JWT é inválida?

As causas mais frequentes são uma chave errada (outro ambiente, chave retirada), um segredo mal codificado, um token alterado ou truncado, ou uma chave que não corresponde ao algoritmo declarado. No servidor, imponha sempre o algoritmo esperado em vez de confiar no campo alg, para evitar os ataques de confusão de algoritmo descritos na RFC 8725.

O que é a tolerância de relógio (leeway)?

É uma margem acrescentada no controlo de exp e nbf para compensar uma pequena diferença entre o relógio do emissor e o do verificador. Com 60 segundos de tolerância, um token expirado há 30 segundos ainda é aceite. A maioria das bibliotecas usa um valor entre 0 e 5 minutos.

Posso colar uma chave ou um segredo nesta ferramenta?

Uma chave pública não é secreta e pode ser colada sem risco. Um segredo HMAC é: aqui a verificação é executada no seu navegador com a Web Crypto API e nada é transmitido, mas evite ainda assim usar um segredo de produção num computador partilhado.

Fluxo de trabalho recomendado

Continue o processamento

Descubra ferramentas que se integram naturalmente antes, depois ou em conjunto com esta.

Usar antes

Descodificador JWT

Descodifique um JWT para ler o cabeçalho, o payload, os claims e as datas de expiração.

Segurança e privacidadeEm destaqueUtilizar esta ferramenta

Funciona bem com

Inspetor JWK / JWKS

Analise uma chave JWK ou um JWKS: kid, kty, alg, use, impressão RFC 7638 e aviso se uma chave privada estiver exposta.

Segurança e privacidadeUtilizar esta ferramenta

Codificador JWT

Crie e assine um JWT HS256, HS384 ou HS512 a partir de um cabeçalho, de um payload JSON e de um segredo.

Segurança e privacidadeUtilizar esta ferramenta

Leia também