JWT (JSON Web Token) é um padrão aberto definido pelo IETF no RFC 7519 (RFC 7515 descreve a forma de assinatura JWS, RFC 7516 descreve criptografia JWE, RFC 7517 define chaves JWK) para transferir com segurança informações de usuário 'declaradas' entre requisições HTTP, fluxos OIDC e chamadas de microsserviços. Uma string JWT padrão é composta por três segmentos codificados em Base64URL: Header (algoritmo e tipo), Payload (Claims, os dados do usuário) e Signature (uma assinatura baseada em chave sobre os dois primeiros). Os três segmentos são unidos por um ponto `.`, ex.: `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.
**JWT não é criptografia.** Este é o equívoco mais comum. O Payload é texto plano por padrão — qualquer um pode decodificar em Base64URL e ler o conteúdo. JWT fornece **detecção de violação**, não confidencialidade: o servidor reassina Header.Payload com a chave compartilhada e compara com a Signature do token. Se coincidirem, o token não foi alterado em trânsito. Esta é a metáfora do 'bilhete de trem com carimbo antifalsificação': o inspetor se importa se o bilhete é genuíno, não se o QR code está ilegível.
JWT divide responsabilidades claramente entre 13 algoritmos. **Família HMAC** (HS256/HS384/HS512) usa uma chave simétrica para assinatura e verificação, rápida e simples, adequada para um único serviço ou cluster confiável; o segredo deve ter pelo menos o comprimento do digest (ex.: ≥ 32 bytes para HS256). **Família RSA** (RS256/RS384/RS512) usa RSASSA-PKCS1-v1_5, o esquema assimétrico mais comum — signatários têm a chave privada, verificadores têm a chave pública. **Família RSA-PSS** (PS256/PS384/PS512) usa o preenchimento RSA-PSS mais recente com garantias de segurança mais fortes, preferido por AWS SigV4 e provedores de identidade OIDC modernos. **Família ECDSA** (ES256/ES384/ES512) usa curvas elípticas (P-256/P-384/P-521 respectivamente) com assinaturas mais curtas e melhor desempenho. **EdDSA** (principalmente Ed25519) é extremamente rápido e determinístico (mesma mensagem + mesma chave = mesma assinatura sempre) e é o algoritmo recomendado no OAuth 2.1 e novos protocolos.
Segurança é onde JWT tropeça em produção. O OWASP JWT Cheat Sheet destaca pelo menos quatro regras rígidas: (1) nunca coloque senhas, documentos de identidade, números de cartão ou chaves de API como texto plano no Payload; (2) o servidor deve **nunca confiar no campo alg** declarado no Header do Token — deve verificar com um algoritmo fixo, caso contrário um atacante reescrevendo o header para `alg: none` contorna tudo (esta é a raiz de CVEs históricos como CVE-2015-9235); (3) segredos HMAC devem ser aleatórios e ter pelo menos 32 bytes, nunca strings curtas; (4) verificação é mais do que apenas verificações de assinatura — você também deve validar `exp` (expiração), `nbf` (not-before), `iss` (emissor) e `aud` (audiência). Esta ferramenta destaca cada um desses Claims na interface para que você possa dizer à primeira vista se uma falha é um problema de assinatura, um problema de tempo ou um problema de Claims.
JWT não é um substituto para sessões. Sessões armazenam estado do usuário no servidor (Redis ou banco de dados); JWT empacota o estado no token. Arquiteturas de microsserviços, APIs sem estado, clientes móveis e configurações com muito CORS se beneficiam do JWT; sistemas empresariais tradicionais e fluxos que requerem revogação instantânea (ex.: 'expulsar este usuário agora') ainda são melhor atendidos por sessões. Esta ferramenta cobre tanto depuração pura de JWT quanto as etapas de parsing de Token / verificação de assinatura / edição de Payload de uma migração de sessão para JWT.