Ir para o conteúdo
UtilDock

Codificador JWT

Monte um token a partir de claims e assine de verdade · roda nesta aba, nunca é enviado a lugar nenhum

Cabeçalho

Payload

Chave de assinatura

A chave é usada e descartada — nunca salva neste navegador, nunca enviada a lugar algum.

Uma chave de assinatura gera tokens que seus sistemas vão aceitar. Para uma chave de produção, prefira o seu próprio ambiente.

HS256

Token assinado

O token assinado aparece aqui. Nada é enviado para produzi-lo: a assinatura é calculada por este navegador.

Escreva um payload e escolha uma chave para gerar um token

Como funciona o Codificador JWT

Um codificador de JWT que produz um token de fato assinado, não um sósia em base64. Escreva o cabeçalho e o payload como JSON, escolha um algoritmo e cole o segredo compartilhado para um algoritmo HS ou uma chave privada PKCS#8 para RS, PS ou ES — a assinatura é calculada pela própria WebCrypto do seu navegador. Expiração, emissão e «não antes de» podem ser carimbados a partir de presets, então você nunca mais converte um epoch na mão.

Escreva o cabeçalho e o payload como JSON, escolha um algoritmo, e o token é montado e assinado enquanto você digita. Os presets de expiração carimbam iat, exp e opcionalmente nbf no payload a partir de um mesmo instante, para que os três nunca discordem por um segundo — exatamente o tipo de falha que só aparece dentro da tolerância de desvio de relógio de outro sistema.

alg é sempre escrito a partir do algoritmo que você escolheu, diga o que disser o seu cabeçalho. Isso não é conveniência: um cabeçalho que declara um algoritmo sobre uma assinatura feita com outro é o ponto de partida da vulnerabilidade de JWT mais conhecida, e não existe token legítimo que esta ferramenta se recuse a criar por causa disso. Qualquer outro campo de cabeçalho que você escrever é mantido exatamente como digitado.

Segredos HS mais curtos que o hash são recusados por padrão — a RFC 7518 exige 32 bytes para HS256, 48 para HS384 e 64 para HS512, e um navegador assina tranquilamente com quatro caracteres, mesmo que o resultado seja quebrável offline em segundos. A verificação pode ser desligada, porque reproduzir um token fraco às vezes é justamente a tarefa.

A chave de assinatura é tratada como o decodificador trata sua chave de verificação, e com ainda mais cuidado: nunca é escrita em localStorage, nunca é restaurada ao recarregar, nunca aparece em um evento de analytics, e não há backend que pudesse recebê-la. Uma chave de assinatura é o segredo mais perigoso de um sistema que usa JWT, então, para uma chave de produção, gerar tokens no seu próprio ambiente continua sendo o melhor hábito.

Perguntas frequentes

É seguro colar uma chave de assinatura neste codificador?

A chave é usada na sua própria aba e descartada: nunca é gravada no armazenamento, nunca entra em um evento de analytics, e não há backend que pudesse recebê-la. Dito isso, uma chave de assinatura é o segredo mais perigoso de qualquer sistema que use JWT, porque quem a tiver pode gerar tokens que seus serviços vão aceitar. Para uma chave de produção, gerar tokens no seu próprio ambiente continua sendo o melhor hábito; esta ferramenta foi feita para desenvolvimento, testes e aprendizado.

Com quais algoritmos ele consegue assinar?

HS256, HS384 e HS512 com um segredo compartilhado, e RS256/384/512, PS256/384/512 e ES256/384/512 com uma chave privada em bloco PEM PKCS#8 ou como JWK privado. Ele também produz o token não protegido com `alg: none`, claramente marcado como algo que não prova nada, porque reproduzir um é justamente como se testa que o seu verificador o rejeita.

Por que ele recusa meu segredo curto?

A RFC 7518 exige uma chave HMAC pelo menos tão longa quanto o hash: 32 bytes para HS256, 48 para HS384 e 64 para HS512. Navegadores assinam tranquilamente com um segredo de quatro caracteres, e o token resultante pode ser quebrado offline em segundos. O codificador bloqueia isso por padrão e deixa você ignorar a regra, já que reproduzir um token fraco às vezes é exatamente a tarefa.

Ele pode sobrescrever o algoritmo do meu cabeçalho?

Ele sempre escreve `alg` a partir do algoritmo que você escolheu, e isso é deliberado. Um cabeçalho que declara um algoritmo sobre uma assinatura feita com outro não é um token: é o ponto de partida da vulnerabilidade de JWT mais conhecida. Qualquer outro campo de cabeçalho que você escrever — `kid`, `cty`, o que for — é mantido exatamente como digitado.