Assinar e verificar JWT

Qual a diferença entre esta ferramenta e o JWT Decoder do site?

O JWT Decoder só lê um token — decodifica em Base64URL o cabeçalho e o payload e mostra os claims, mas nunca checa a assinatura. Isso resolve "o que este token diz", mas não responde "esse token é legítimo", porque um token totalmente forjado com qualquer payload inventado decodifica tão limpo quanto um de verdade. Esta ferramenta roda a verificação criptográfica de fato: recalcula a assinatura a partir do cabeçalho e do payload usando o segredo ou a chave pública que você fornece, compara byte a byte com a assinatura que veio no token, e só depois reporta os claims de tempo. Uma diferença bem concreta aparece no caso alg: "none": pela RFC 7519 §6, um "JWT sem segurança" é um token com alg: "none" e a parte da assinatura vazia, e como o decoder só lê, ele continua decodificando esse token normalmente e coloca o rótulo de aviso "Sem segurança" em cima. Já esta ferramenta de verificação rejeita esse token de cara, sem exceção — não existe caminho para ele "passar" na aba Verificar.

Por que o resultado tem três estados diferentes em vez de só "válido" ou "inválido"?

Porque "inválido" na verdade cobre três falhas bem diferentes, cada uma com uma solução diferente. Assinatura inválida significa que o token foi assinado com uma chave diferente da que você forneceu — segredo errado, chave pública errada, ou o payload foi alterado. Token expirado tem uma assinatura perfeitamente válida; quem emitiu fez tudo certo, o token só sobreviveu ao próprio claim "exp" — a solução é pedir um token novo, não suspeitar de forjamento. Algoritmo rejeitado significa que o cabeçalho do token declara um algoritmo diferente do que você pediu para esta ferramenta checar, o que é um desalinhamento de configuração ou, no pior caso, uma tentativa de ataque. Juntar os três num único selo "inválido" não diria nada útil para alguém depurando um erro 401 sobre qual desses três problemas bem distintos está enfrentando.

O que é a vulnerabilidade "alg: none", e como esta ferramenta evita ela?

Algumas bibliotecas JWT antigas aceitavam um token cujo cabeçalho declarasse "alg": "none" e tratavam uma assinatura vazia como automaticamente válida — a biblioteca via "nenhum algoritmo pedido" e pulava a verificação inteira, o que significava que qualquer pessoa podia forjar um token com os claims que quisesse só definindo esse campo de cabeçalho e não colocando nada depois do último ponto. Esta ferramenta evita essa classe inteira de bug ao nunca perguntar "o cabeçalho manda pular a verificação?" — você escolhe antes o algoritmo esperado (HS256, RS256 etc.), e essa expectativa é aplicada como uma lista de permissão explícita via o parâmetro algorithms da biblioteca jose. Se o cabeçalho do token declarar qualquer outra coisa — "none" incluído — a verificação é rejeitada antes mesmo de tocar no material da chave, do jeito que uma biblioteca backend séria sobre segurança deveria se comportar. Isso também bloqueia o clássico ataque de "confusão de algoritmo": usar a chave pública do RS256 como se fosse um segredo HMAC para validar uma assinatura HS256 forjada — porque a ferramenta sempre fixa o algoritmo de verificação pela sua escolha, nunca lendo o algoritmo do próprio token para decidir como checá-lo.

Uma assinatura válida significa que o token ainda pode ser usado?

Não necessariamente — é exatamente por isso que existe o estado expired separado do valid. A assinatura só prova que o token veio de quem detém a chave e que o conteúdo não foi alterado; ela não diz nada sobre o token ainda estar "vivo". Um token com assinatura perfeitamente correta mas com o claim exp no passado retorna o estado expired, com o detalhe "a assinatura é válida, mas o claim exp está no passado". Da mesma forma, se o claim nbf (not-before) ainda está no futuro, a ferramenta reporta notYetValid mesmo com a assinatura certa. Só quando todos os claims de tempo batem e a assinatura confere é que o resultado final vira valid.

Que formato de chave a via RS256 / ES256 espera?

Para assinar, é esperada uma chave privada PEM no formato PKCS#8 (o bloco começa com -----BEGIN PRIVATE KEY-----). Para verificar, é esperada uma chave pública PEM no formato SPKI (-----BEGIN PUBLIC KEY-----). São exatamente os formatos que o crypto.subtle.importKey do WebCrypto entende nativamente — a biblioteca jose usada por esta ferramenta é só uma camada mais conveniente sobre o WebCrypto, sem mecanismo próprio de leitura de chave. Chaves PKCS#1 antigas (-----BEGIN RSA PRIVATE KEY-----) usam uma codificação diferente que o WebCrypto não lê diretamente; é preciso converter antes com openssl pkcs8 -topk8 -nocrypt.

É seguro assinar ou verificar uma chave de produção numa ferramenta de navegador?

Verificar é de baixo risco: você só cola uma chave pública ou um segredo compartilhado cujo destinatário já é de confiança, e nada do que você digita é enviado a lugar nenhum — a checagem roda com o WebCrypto nativo do navegador, inteira dentro desta aba. Assinar é o caso que merece mais cuidado: uma chave privada colada em qualquer aba fica exposta ao JavaScript daquela aba enquanto ela estiver aberta, e a qualquer pessoa ou extensão maliciosa com acesso ao dispositivo nesse período. Para um token de teste descartável, essa é uma troca razoável pela conveniência; para uma chave privada que protege um sistema de produção real, assine no seu backend ou pipeline de CI com uma biblioteca server-side já validada — a mesma cautela que os geradores de chave deste site já recomendam.