Assinador e verificador de JWT

Assine um token com a sua chave, verifique um token com um segredo, PEM, JWK ou JWKS ao vivo — e crie o conjunto de chaves que a sua API publica. Toda a criptografia corre no seu navegador.

Um JWT só é tão confiável quanto a sua assinatura. Qualquer pessoa pode ler um token — descodificar não prova nada — por isso esta ferramenta faz a parte que um descodificador não consegue: assina tokens com a sua chave (HS256/384/512, RS256/384/512, ES256/384/512, EdDSA), verifica-os com um segredo, uma chave pública PEM ou JWK, um JWKS colado ou um URL JWKS ao vivo com correspondência de kid, e cria o JWKS que a sua própria API publica. O guia complementar assinar e verificar JWTs explica por que descodificar não é verificar, como funciona o ataque de confusão de algoritmo e o que "verificado" prova — e o que não prova. Para ler um token sem chave, use o descodificador JWT; para as chaves em si, o SSH Key Suite cobre geração e conversão.

Última atualização:

Assinar um token

🔒 A assinatura e a verificação acontecem localmente com WebCrypto. Segredos e chaves privadas nunca são enviados, armazenados ou registados — recarregue a página e eles desaparecem.

As suas chaves nunca saem desta página

A assinatura e a verificação usam o WebCrypto do seu navegador, com chaves que você cola ou gera aqui. Segredos e chaves privadas vivem apenas na memória da página: não são enviados, não são escritos no localStorage nem em cookies e nunca aparecem no URL. Recarregue ou feche a página e eles desaparecem. A única exceção é a busca de um URL JWKS, que você inicia: ela envia apenas o URL que você digitou, para buscar chaves públicas — nunca um segredo. Leia assinar e verificar JWTs antes de colar uma chave de produção em qualquer lugar.

Os limites honestos

EdDSA precisa de um navegador atual: WebCrypto Ed25519 não existe em navegadores mais antigos, e esta página diz isso claramente em vez de fingir uma assinatura. ECDSA P-256 é oferecido como a alternativa que funciona em todo o lado.

PEM cifrado (uma chave privada bloqueada com uma frase-passe) não é suportado na versão 1. A página recusa-o abertamente — decifre-o primeiro com openssl pkcs8 -topk8 -nocrypt e nunca cole uma frase-passe numa página web.

A busca de um URL JWKS depende de o servidor enviar cabeçalhos CORS. Muitos fornecedores de identidade enviam; quando um não envia, a busca falha honestamente e a página diz-lhe para colar o JWKS. Só chaves públicas são buscadas — um URL JWKS nunca transporta um segredo.

Quando assinar supera descodificar

Descodificar um JWT é lê-lo: o cabeçalho e o payload são base64url, e qualquer pessoa com o token pode ver ambos. É por isso que um descodificador, sozinho, nunca consegue responder à única pergunta que importa — o emissor assinou mesmo isto? Assinar é a outra metade do trabalho: quem detém a chave privada (ou o segredo HMAC) produz a assinatura, e a verificação repete a mesma matemática com a chave pública. Esta página mantém ambas as metades no seu navegador, porque as chaves envolvidas são os dados mais sensíveis que uma ferramenta web alguma vez manipula.

A separação importa mais nos algoritmos assimétricos. Com HS256, o segredo que verifica é o mesmo segredo que assina — qualquer pessoa que consiga verificar os seus tokens também os pode emitir, o que é bom dentro de um serviço e uma fuga em qualquer outro lugar. Com RS256, ES256 ou EdDSA, a chave de assinatura fica com o emissor e só a chave pública viaja: a sua API pode publicar o seu JWKS, rodar chaves adicionando um novo kid e deixar que todos os verificadores do mundo verifiquem tokens sem nunca deterem o poder de forjar um.

O que a ferramenta se recusa a fazer

Duas recusas são deliberadas. A primeira é alg: none: um token que afirma não precisar de assinatura é rejeitado de imediato, com o motivo à vista — um verificador que o aceite aceita falsificações. A segunda é a confusão de algoritmo: um token RS256 apresentado com um segredo HMAC (ou o inverso) falha com um aviso explícito, nunca reinterpretando silenciosamente a chave na outra família. Ambos são ataques clássicos a JWT, e ambos são bloqueados estruturalmente aqui — a família da chave tem de corresponder à família do alg do token, ou a verificação falha.

A terceira recusa é mais subtil: esta página nunca lhe diz que um token é "confiável". Uma assinatura válida prova que o token foi assinado com uma chave, e a verificação de expiração prova que está dentro da sua janela — nada mais. Decidir se confia nessa chave é uma decisão sobre a sua origem: um JWKS buscado no URL bem conhecido do seu fornecedor de identidade, uma chave pública que você fixou, um segredo que você gerou. O guia assinar e verificar JWTs explica o que "verificado" prova e o que não prova.

Termos de JWT, definidos

JWT. JSON Web Token (RFC 7519): uma forma compacta e segura para URL de transportar claims entre partes — cabeçalho.payload.assinatura, cada um codificado em base64url. O payload pode ser lido por qualquer pessoa; só a assinatura depende do segredo.

JWS. JSON Web Signature (RFC 7515): o formato de assinatura por baixo dos JWTs. Um JWT é um JWS cujo payload é um conjunto de claims JSON.

JWK. JSON Web Key (RFC 7517): um objeto JSON que representa uma chave criptográfica — kty e o material da chave (n/e para RSA, x/y para EC, x para Ed25519, k para um segredo partilhado).

JWKS. JSON Web Key Set: um objeto com um array "keys" — a forma padrão de um emissor publicar as suas chaves públicas, geralmente em /.well-known/jwks.json.

kid. Key ID: a claim do cabeçalho que diz qual chave assinou um token. Um verificador compara-a com o JWKS; sem ela, usa-se um conjunto de uma só chave e a página diz isso.

alg. A claim do cabeçalho que nomeia o algoritmo de assinatura (HS256, RS256, ES256, EdDSA…). Um verificador tem de fixar os algoritmos que aceita — confiar no alg declarado pelo próprio token é o ataque de confusão.

HMAC. Hash-based Message Authentication Code: uma assinatura simétrica — o mesmo segredo assina e verifica. Rápido e simples; quem detém o segredo pode emitir tokens.

RSASSA-PKCS1-v1_5. O esquema de assinatura RSA por trás de RS256/384/512: o hash é encapsulado e elevado ao expoente privado. Determinístico — a mesma entrada produz sempre os mesmos bytes de assinatura.

EdDSA. Edwards-curve Digital Signature Algorithm: Ed25519 aqui — chaves pequenas, verificação rápida, assinaturas determinísticas. Precisa de um navegador atual para suporte WebCrypto.

Perguntas frequentes

É seguro colar uma chave privada nesta página?

Nesta página, a chave nunca sai do seu navegador: a assinatura corre na memória da página com WebCrypto, nada é enviado, armazenado ou registado, e um recarregamento apaga tudo. O padrão inseguro é um assinador no servidor, onde a sua chave privada atravessa a rede. Mesmo localmente, use um dispositivo em que confie — e trate uma chave de produção colada como exposta se a máquina for partilhada. Gere antes chaves de teste aqui, em vez de colar chaves reais.

Por que o meu token RS256 não verifica com o meu segredo?

Porque um segredo e uma chave RSA são famílias diferentes, e a página recusa-se a misturá-las — essa recusa é a proteção contra confusão de algoritmo. Um token RS256 precisa da chave pública RSA do emissor (PEM, JWK ou JWKS); um segredo só consegue verificar HS256/384/512. Se tem a chave pública na forma errada, converta-a: a aba JWKS converte PEM ⇄ JWK.

O que uma busca de URL JWKS envia, na verdade?

Um pedido GET ao URL que você digitou, pedindo JSON. Nenhuma chave, nenhum segredo, nenhum token e nenhum identificador vai com ele — a resposta é um conjunto de chaves públicas. Se o servidor não enviar cabeçalhos CORS, o navegador bloqueia a leitura e a página diz-lhe para colar o JWKS.

O meu token verifica aqui, mas a API rejeita-o. Porquê?

A verificação aqui confere a assinatura e a janela de tempo com a chave que você forneceu. Uma API também verifica as claims: o emissor (iss) que espera, a audiência (aud) que serve e se o id da chave (kid) é um em que confia atualmente. Um token assinado com uma chave já rodada, ou emitido para outra audiência, verifica-se matematicamente e mesmo assim é recusado — corretamente.

EdDSA não funciona no meu navegador. E agora?

Ed25519 precisa de um navegador atual — os mais antigos não têm WebCrypto Ed25519, e esta página diz isso em vez de fingir. Use ES256 (ECDSA P-256) como alternativa: é suportado em todo o lado onde existe WebCrypto, e a página pode gerar a chave para você. Se tem mesmo de usar Ed25519, atualize o navegador.