Gerar token JWT
Crie um JWT assinado com os seus próprios dados: informe um assunto, um papel como admin e um segredo compartilhado e receba um token HS256 pronto para usar, ou assine com uma chave privada em RS256. A sua chave é usada uma vez e descartada. Grátis no seu navegador.
- Grátis
- Funciona no seu navegador
- Sem cadastro
- Seus dados não saem do seu aparelho
Executar grátis
Esta ferramenta monta e assina um JWT completo: você define as claims, informa a chave secreta e recebe o token pronto para usar. Ideal para testar APIs protegidas sem subir um serviço de autenticação — e tudo é assinado dentro do seu navegador, sem a chave sair da página.
Quando faz sentido assinar um token você mesmo
Provedores de identidade completos existem para o login de usuários, mas muito trabalho legítimo acontece fora desse caminho: chamadas entre serviços que precisam de um token de curta duração, ambientes de teste que precisam de um token com o papel de um usuário específico, scripts de homologação que se passam por um cliente para reproduzir um bug e ferramentas internas que liberam acesso temporário e restrito. Montar um servidor de autenticação inteiro para isso é exagero; uma única assinatura não é. O cuidado está nos detalhes: um formato de expiração errado ou a falta do público-alvo pode quebrar todos os serviços seguintes.
HS256 ou RS256, e o que acontece com a sua chave
O HS256 assina e verifica com o mesmo segredo compartilhado, o que é simples quando um serviço ou um grupo pequeno de confiança controla as duas pontas. O RS256 assina com uma chave privada e permite que qualquer um verifique com a chave pública, ideal quando vários serviços independentes conferem tokens sem nunca ter o segredo. A sua chave é usada só nessa assinatura e depois descartada, sem registro nem reaproveitamento. Dados estruturalmente inválidos, como uma expiração que não é número, são recusados antes de assinar. A expiração é dada em segundos; sem ela, o token não expira.
Para que serve um token feito à mão
Reproduzir o bug que só acontece com um usuário de perfil específico — basta assinar um token com aquelas claims exatas. Demonstrar um fluxo para o cliente sem criar usuário de verdade. Em todos esses casos, gerar o token na mão economiza o desvio de provisionar contas.
exp, iat e a arte de não criar bomba-relógio
Dois erros opostos aparecem sempre. Token de teste com expiração curta demais: o teste falha meia hora depois e ninguém entende por quê. Token de longa duração que vaza para produção: uma credencial quase eterna circulando.
A prática saudável é expiração generosa em homologação, curta em produção — e nunca reaproveitar o mesmo segredo nos dois ambientes, para que um token de teste jamais seja aceito no ambiente real.
Casos de uso
Reproduzir bug de permissão
Um usuário com papel de aprovador relata um erro que ninguém consegue reproduzir. O dev assina um token com exatamente aquele papel e aquelas claims — e o bug aparece na primeira tentativa.
Perguntas frequentes
O segredo que eu digito é guardado em algum lugar?
Não. A assinatura acontece no navegador e a chave não sai da página nem é registrada. Se preferir, use um segredo descartável de teste — a boa prática de nunca digitar segredo de produção fora do cofre continua valendo.
Posso usar os tokens gerados aqui em produção?
Tecnicamente eles são JWTs válidos como quaisquer outros; na prática, produção deve emitir tokens no backend, dentro do fluxo de login. Esta ferramenta brilha em teste, homologação e depuração — não como emissor oficial do seu sistema.
Que tipo de assinatura o token recebe?
Assinatura simétrica, do tipo em que a mesma chave assina e valida — o formato dominante em testes. O importante: o algoritmo do token precisa ser exatamente o que o seu backend espera; se ele valida com chave pública (RSA ou ECDSA), um token simétrico será rejeitado.
Por que meu backend rejeita o token que eu gerei?
Confira, nesta ordem: o segredo é idêntico ao configurado no backend? O algoritmo bate? O exp já passou? As claims obrigatórias (aud, iss) estão presentes e com os valores esperados? Nove entre dez rejeições moram numa dessas quatro.
Isso funciona no celular?
Sim, no navegador mesmo — útil para gerar um token rápido no meio de uma reunião ou de um plantão, sem abrir o notebook.
Ferramentas relacionadas
Para desenvolvedores — acesso via API
Tudo nesta página está disponível via API. Esta seção é para equipes que querem integrar a ferramenta aos próprios sistemas; quem não precisa disso pode simplesmente usar a ferramenta acima.
Endpoint
Autenticação por token Bearer. Um único POST coloca a tarefa na fila; o resultado chega por webhook ou link assinado.
Chame do seu código
curl -X POST https://api.kit.forhosting.com/dev/jwt-sign \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"payload":{"sub":"user_1"},"secret":"s3cr3t"}'const res = await fetch("https://api.kit.forhosting.com/dev/jwt-sign", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"payload": {
"sub": "user_1"
},
"secret": "s3cr3t"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/jwt-sign",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"payload": {
"sub": "user_1"
},
"secret": "s3cr3t"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/jwt-sign", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"payload":{"sub":"user_1"},"secret":"s3cr3t"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"payload":{"sub":"user_1"},"secret":"s3cr3t"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/jwt-sign", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemplo de requisição
{
"payload": {
"sub": "user_1"
},
"secret": "s3cr3t"
}Exemplo de resposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.jwt_sign",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}A API é assíncrona: cada chamada devolve um task_id na hora. Se preferir polling, consulte o status a até 1 requisição por segundo.
Preço
Preço publicado, sem tokens nem créditos escondidos. Tarefa que falha não é cobrada.
Erros
| HTTP | Código | O que significa |
|---|---|---|
401 | unauthorized | Token ausente ou inválido. Confira o header Authorization. |
402 | insufficient_balance | Saldo insuficiente para esta tarefa. Faça uma recarga e tente de novo. |
404 | unknown_type | Esse tipo de tarefa não existe. Confira o campo type no catálogo. |
429 | rate_limited | Muitas requisições em pouco tempo. Espere um instante e tente de novo. |
Notas técnicas
Monte o payload, assine, use
Sem instalar biblioteca, sem script descartável, sem depender do serviço de autenticação estar de pé. O fluxo é direto: escreva as claims em JSON — sub, exp, papéis, o que o seu sistema espera —, informe o segredo de assinatura e copie o token gerado. Em segundos você tem uma credencial válida para mandar no header Authorization e exercitar a API como se um usuário real tivesse feito login.
Para que serve um token feito à mão
Testar um endpoint protegido antes do serviço de login existir. Preparar coleções de testes de API com credenciais de longa duração para homologação.
A chave fica no seu navegador
A assinatura é calculada localmente: o segredo que você digita não é transmitido nem armazenado — fechou a aba, acabou. Para gerar tokens dentro de um fluxo automatizado (provisionar credenciais de teste no CI, por exemplo), a mesma operação existe via API por US$ 0,002 por chamada; nesse caso a chave viaja na requisição e não fica guardada.
Casos de integração
Testar a API antes do login existir
O backend da API ficou pronto antes do serviço de autenticação. O time gera tokens com as claims combinadas e valida todos os endpoints protegidos semanas antes da integração real.
Credencial estável para testes automatizados
A suíte de testes de integração precisa de um token válido a cada execução. Um passo do pipeline gera o JWT via API na hora, com expiração curta, em vez de manter uma credencial fixa commitada no repositório.
Perguntas técnicas
Quanto custa gerar tokens pela API?
US$ 0,002 por chamada — publicado, sem surpresa, sem mínimo. O pagamento é direto por PayPal; na página, o uso é grátis e sem cadastro.