O que esta ferramenta faz
Este codificador JWT assina um JSON Web Token inteiramente no teu navegador. Escolhe um algoritmo, edita o header e o payload, cola a chave de assinatura (um segredo partilhado para HMAC; uma chave privada PEM PKCS#8 para RSA ou ECDSA) e obténs um token assinado completo, pronto a colar num pedido, num fixture ou numa configuração.
Algoritmos suportados: HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512 e EdDSA (Ed25519). alg: none também é suportado, mas a interface sinaliza-o como o risco de segurança que é (token sem assinatura).
A entrada da chave aceita o que a maioria das ferramentas de CLI emite. As chaves privadas RSA podem ser coladas como PKCS#8 (BEGIN PRIVATE KEY) ou como PKCS#1 (BEGIN RSA PRIVATE KEY) — o TaskKit envolve o corpo PKCS#1 em PKCS#8 com um pequeno leitor ASN.1 próprio antes de o entregar ao WebCrypto, sem necessidade de passar por openssl pkcs8 -topk8. EdDSA aceita a seed privada de 32 bytes como 64 caracteres hex, 43 caracteres base64url, JWK ou PEM PKCS#8. Chaves PKCS#8 cifradas (BEGIN ENCRYPTED PRIVATE KEY) são rejeitadas com uma sugestão de uma linha para descifrar; chaves privadas EC SEC1 (BEGIN EC PRIVATE KEY) são rejeitadas com uma sugestão de uma linha para conversão.
Quando usar
- Gerar um token para um teste de integração local em que controlas as duas pontas.
- Produzir um fixture para um teste unitário que precisa de uma string com a forma de um token e uma assinatura real.
- Reproduzir um bug a partir de um token funcional, mexendo num claim e voltando a assinar com a mesma chave.
- Construir um token de exemplo para um colega durante uma sessão de depuração, sem expor o segredo num site partilhado.
Como funciona
A assinatura usa crypto.subtle.sign, a API WebCrypto integrada no navegador. As chaves HMAC são importadas a partir de bytes em bruto; as chaves privadas RSA e ECDSA são importadas como PKCS#8 (PKCS#1 é convertido on the fly). EdDSA passa por @noble/ed25519 porque o suporte WebCrypto para Ed25519 ainda é irregular. O codificador constrói base64url(header).base64url(payload).base64url(assinatura) e isso é o token.
O campo alg do header é sempre sobreposto para corresponder ao algoritmo escolhido, mesmo que tenhas escrito algo diferente no textarea do header. typ: "JWT" é adicionado por defeito se não o tiveres incluído. Os campos personalizados do header (kid, x5t, e quaisquer outros) são preservados.
O header, o payload e a chave de assinatura nunca saem do teu navegador. Não há etapa de servidor.
Notas
Onde arranjo uma chave privada? Para RSA: openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048 produz um PEM PKCS#8 (BEGIN PRIVATE KEY). Os blocos PKCS#1 mais antigos (BEGIN RSA PRIVATE KEY) são aceites diretamente — não é preciso converter. Para EdDSA: openssl genpkey -algorithm Ed25519 funciona e o TaskKit lê o PEM PKCS#8 resultante. As chaves privadas EC SEC1 (BEGIN EC PRIVATE KEY) têm de ser convertidas primeiro com openssl pkcs8 -topk8 -nocrypt -in sec1.pem -out pkcs8.pem.
Devo assinar tokens com alg: none? Quase nunca. O token sem assinatura não tem proteção de integridade e qualquer verificador que o aceite pode ser enganado. O codificador produ-lo por completude e avisa explicitamente; trata o resultado como apenas-para-testes.
HS ou RS para código novo? RS256 (ou ES256) quando uma parte externa verifica — só precisa da chave pública. HS256 quando o mesmo serviço está nos dois lados.
Ferramentas relacionadas
- Descodificador JWT — cola um token para o inspecionar ou verificar
- Gerador de hashes — se realmente queres um digest, não um token
- Conversor de timestamp — para valores
expeiatlegíveis