Gerador de JWT
Seu segredo é usado apenas nesta página e nunca é enviado, armazenado ou colocado na URL — então um link compartilhado não pode vazá-lo. Nunca cole um segredo de assinatura de produção em nenhum site, incluindo este; use um segredo descartável para testes.
Só HS256, HS384 e HS512 são suportados. Assinar com RS, ES e PS exige uma chave privada, que esta ferramenta deliberadamente não pede.
Nada do que você digita aqui é armazenado, registrado ou compartilhado.
Monte um payload JWT, escolha um algoritmo e assine com seu segredo. A assinatura acontece inteiramente no seu navegador, então o segredo nunca sai do seu dispositivo.
Como usar
- Edite o payload como JSON.
- Opcionalmente escolha uma expiração, o que adiciona iat e exp automaticamente.
- Informe seu segredo; o token assinado aparece abaixo.
O que a assinatura produz
Um JWT são três segmentos base64url unidos por pontos. O primeiro é o header, que diz qual algoritmo foi usado. O segundo é o payload, com as suas claims. O terceiro é a assinatura, calculada sobre os dois primeiros segmentos unidos por um ponto - e o que é assinado são os bytes exatos desses segmentos, não o JSON que eles representam, e é por isso que reserializar um token o invalida.
Com HS256, a assinatura é um HMAC dessa entrada usando o seu segredo. Qualquer um com o mesmo segredo pode recalculá-la e ver se confere, o que prova duas coisas: o token foi emitido por alguém que conhecia o segredo, e nada nele foi alterado desde então. Mude um único caractere do payload e a assinatura recalculada deixa de bater.
O que ela não faz é esconder nada. O payload é codificado, não criptografado, e qualquer pessoa com o token lê todas as claims sem o segredo. Nunca coloque uma senha, um número de cartão ou qualquer coisa que você não imprimiria num log no payload de um JWT.
Escolhendo um segredo
A RFC 7518 exige uma chave HMAC com pelo menos o tamanho da saída do hash: 256 bits para HS256, 384 para HS384, 512 para HS512. Isso significa no mínimo 32 bytes aleatórios, e não uma frase fácil de lembrar.
O motivo é que um JWT é um ataque offline pronto para usar. Ele contém a entrada assinada e a assinatura juntas, então quem obtiver um único token pode testar segredos candidatos contra ele tão rápido quanto o hardware permitir, sem ida e volta pela rede e sem nada para limitar a taxa. Existem ferramentas públicas que fazem exatamente isso, e uma palavra de dicionário ou uma string curta cai em segundos. Um token vazado com segredo fraco significa que o atacante pode emitir os próprios tokens com as claims que quiser.
Use um valor aleatório de um gerenciador de senhas ou gerador de chaves, mantenha segredos separados por ambiente para que um token de staging não possa ser reaproveitado em produção, e faça a rotação como faria com qualquer outra credencial.
As claims que vale definir
Além do que a sua aplicação precisa, a RFC 7519 registra um pequeno conjunto de claims padrão. iss indica o emissor, sub identifica o sujeito, aud indica o público pretendido e jti dá ao token um id único para que ele possa ser revogado individualmente ou verificado contra reutilização. As três claims de tempo - exp para expiração, nbf para o primeiro momento válido, iat para a emissão - são valores NumericDate, ou seja, segundos desde a época Unix.
Segundos, não milissegundos. Passar direto um timestamp de JavaScript é o motivo mais comum de rejeição de um token escrito à mão: um exp de treze dígitos é interpretado como uma data num futuro distante, que algumas bibliotecas recusam na hora e outras aceitam como um token que nunca expira.
Definir o exp não faz o token expirar sozinho. Ele expira porque o verificador confere a claim, e um verificador que só confere a assinatura aceita de bom grado um token do ano passado. A maioria das bibliotecas também tolera uma pequena diferença de relógio, geralmente um ou dois minutos, já que as máquinas que emitem e verificam raramente concordam exatamente.
Por que só os algoritmos HS, e a armadilha do alg
A família HS é simétrica: um único segredo compartilhado assina e verifica, então a assinatura pode acontecer aqui só com o que você digita. RS, ES e PS são assimétricos e exigiriam colar uma chave privada numa página web, algo que esta ferramenta não está disposta a pedir.
O campo do header que indica o algoritmo também é onde moram dois ataques bem conhecidos. O primeiro é alg: none, que declara o token como não assinado; bibliotecas que respeitavam isso podiam receber tokens forjados com assinatura vazia. O segundo é a substituição de algoritmo: pegue um token assinado com RS256, troque o header para HS256 e assine com a chave pública do emissor como segredo HMAC. Um verificador que lê o algoritmo do token, em vez de decidir de antemão, vai aprová-lo tranquilamente, porque a chave pública não é secreta.
A defesa nos dois casos é a mesma e fica no verificador, não no emissor: fixe o algoritmo esperado na chamada de verificação e rejeite qualquer token cujo header discorde.
Projetando o tempo de vida de um token
A escolha de maior consequência em um sistema de tokens é quanto tempo um token vive, porque um JWT não pode ser retirado de circulação antes de expirar. Tempos de vida curtos - de cinco a quinze minutos para um token de acesso - mantêm pequena a janela de um token vazado e são a resposta padrão, combinados com um refresh token de vida mais longa que pode ser revogado porque o servidor o armazena.
A rotação de refresh tokens torna essa combinação significativamente mais segura: cada renovação emite um novo refresh token e invalida o anterior, de modo que um token roubado só serve uma vez. Se o antigo for apresentado de novo, o servidor descobre que duas partes o possuem e pode revogar a família inteira.
Quando é preciso uma credencial realmente de longa duração - uma integração entre máquinas, uma CLI -, o JWT costuma ser o formato errado. Uma API key conferida contra um banco de dados pode ser revogada na hora, ter escopo preciso e aparecer em uma interface onde o dono enxerga quando ela foi usada pela última vez.
Chaves, rotação e o header kid
Uma chave de assinatura deve poder ser trocada sem indisponibilidade, e o mecanismo para isso é o header kid: o emissor diz qual chave assinou o token, e o verificador busca essa chave em vez de supor. Com HS256 isso significa um pequeno mapa de identificadores de chave para segredos; com RS256 ou ES256 significa um documento JWKS que o verificador baixa e mantém em cache.
A rotação tem então três fases. Publique a nova chave para que os verificadores a conheçam, passe a assinar com a nova chave ainda aceitando a antiga, e aposente a antiga depois que todo token assinado com ela tiver expirado. Pular esse período de sobreposição é o que transforma uma rotação rotineira em um incidente.
Algoritmos assimétricos compensam o preparo extra assim que mais de um serviço verifica seus tokens. Com HS256 todo verificador guarda um segredo que também serve para assinar, então qualquer serviço comprometido consegue emitir tokens; com RS256 os verificadores guardam apenas uma chave pública e não conseguem forjar nada.
O que cabe no payload e o que não cabe
Um token é uma credencial bearer que viaja em um header a cada requisição, então o tamanho tem um custo real: proxies costumam limitar headers a 8 KB, e um token inchado é pago em cada chamada. Fique na identidade e nos poucos fatos de que o verificador precisa: subject, issuer, audience, expiração e um conjunto pequeno de escopos ou papéis.
Qualquer coisa volátil se encaixa mal. Permissões gravadas dentro de um token já estão desatualizadas desde o instante em que são emitidas, então um papel revogado às 10h continua sendo afirmado pelos tokens até que eles expirem. Onde isso importa, o token deve carregar identidade e o serviço deve consultar a autorização, ou os tempos de vida devem ser curtos o bastante para que a defasagem seja aceitável.
Nada secreto tem lugar ali. O payload é codificado, não criptografado, então qualquer um com o token lê todas as claims: nada de anotações internas, nada de dados pessoais além do que o destinatário precisa, nada de chaves. Se um payload realmente precisa ser confidencial, isso é JWE, uma especificação diferente com ferramentas diferentes.
Testar tokens sem vazar nada
Um gerador é mais útil para montar fixtures: um token expirado, um que ainda não é válido, um com a audience errada, um assinado com a chave errada. Uma rotina de verificação deve ser testada contra os quatro, e a maioria dos bugs nessa área são casos em que um deles acaba aceito.
Use um segredo de teste, nunca um de produção. É o mesmo argumento válido para qualquer credencial, e aqui ele é mais afiado, porque um token junto com sua assinatura já basta para um ataque offline ao segredo. Segredos separados por ambiente também evitam a falha mais sutil em que um token emitido em staging é aceito em produção.
Tudo nesta página roda no navegador, então nada do que você digita aqui é transmitido ou armazenado. Isso vale saber, dado o que as pessoas colam em ferramentas de token, e é também por isso que os algoritmos assimétricos estão ausentes: assinar com RS256 significaria colar uma chave privada em uma página web, e nenhuma ferramenta deveria pedir isso.
Motivos comuns para um token feito à mão ser rejeitado
Claims de tempo em milissegundos são o caso mais frequente. NumericDate é a contagem de segundos desde a epoch, então um exp de treze dígitos é lido como uma data dezenas de milhares de anos à frente - rejeitado de cara por algumas bibliotecas, aceito como um token eterno por outras, e nenhum dos dois é o que você queria.
O padding vem em seguida. Os segmentos de um JWT usam base64url sem padding, então um token cujos segmentos terminam em sinais de igual, ou que contém os caracteres de mais e barra em vez de menos e sublinhado, foi codificado com o alfabeto errado e vai falhar antes mesmo de a assinatura ser conferida.
O resto costuma ser divergência. A audience que o verificador espera difere por uma barra no final; o issuer está escrito com http e o verificador usa https; o relógio de uma das máquinas está alguns minutos fora e não há tolerância de desvio configurada. Quando um token decodifica corretamente e mesmo assim falha, compare as claims com a configuração do verificador campo a campo antes de suspeitar da assinatura.
Perguntas frequentes
- É seguro informar meu segredo de assinatura?
- O segredo é usado apenas pelo JavaScript desta página. Ele nunca é transmitido, armazenado ou escrito na URL, então compartilhar um link não pode vazá-lo. Ainda assim, trate um segredo de produção como trataria uma senha e use um valor descartável para testes.
- Por que só HS256, HS384 e HS512 são suportados?
- Eles são simétricos, então um único segredo compartilhado assina e verifica. RS, ES e PS são assimétricos e exigiriam colar uma chave privada em um formulário web, algo que esta ferramenta deliberadamente evita pedir.
- O que iat e exp precisam conter?
- Ambos são valores NumericDate medidos em segundos desde a época Unix, não em milissegundos. Escolher uma expiração aqui grava os dois corretamente; informá-los em milissegundos é a forma mais comum de um token escrito à mão acabar rejeitado.
- Posso adicionar campos personalizados ao cabeçalho?
- O cabeçalho é definido com o algoritmo escolhido mais typ JWT. Campos personalizados como kid pertencem a uma configuração específica de gerenciamento de chaves, então é melhor adicioná-los pela biblioteca que emite seus tokens reais.
- Devo usar estes tokens em produção?
- Não. Esta é uma ferramenta de teste e depuração. Tokens reais devem ser emitidos pelo seu serviço de autenticação, que cuida da rotação de chaves, da revogação e da validação das claims.
Última atualização:
Inclua os passos, o resultado esperado e o resultado real. Remova segredos e dados pessoais.