JWT Decoder

O que é um JWT?

Um JSON Web Token (JWT, pronunciado "jot") é um objeto JSON compacto e assinado, definido no RFC 7519. Transporta claims entre duas partes, normalmente entre um servidor de autenticação e uma API. O servidor emite o token após autenticação bem-sucedida, e o cliente anexa-o em cada chamada API através do header `Authorization: Bearer ...`.

Os JWTs consistem em três partes codificadas em base64url e unidas por pontos. Não são encriptados, apenas assinados. Quem tiver o token pode ler o seu conteúdo, por isso passwords e outros segredos nunca devem ir no payload.

A vantagem face a sessões server-side: um JWT é self-contained. Um servidor API pode validar o token e extrair permissões sem contactar o servidor de auth ou consultar uma store de sessão. Isso escala horizontalmente de forma excelente, ao custo de não conseguir revogar tokens individuais antes da expiração.

Header, payload, signature explicados

Cada JWT tem três partes, unidas por pontos:

• Header: pequeno objeto JSON com `alg` (algoritmo, ex: HS256, RS256, ES256) e `typ` (normalmente "JWT"). Por vezes também `kid` (key ID) como pista de qual chave foi usada para assinar.
• Payload: objeto JSON com os claims. Os campos padrão são `iss` (issuer), `sub` (subject), `aud` (audience), `exp` (expiration), `nbf` (not before), `iat` (issued at) e `jti` (ID único do token). Campos personalizados são permitidos em conjunto.
• Signature: calculada sobre `base64url(header) + "." + base64url(payload)` com o algoritmo configurado. Protege a integridade: sem a chave, o conteúdo não pode ser modificado sem ser detetado.

Importante: base64url é codificação, não encriptação. O header e o payload são legíveis para qualquer observador.

JWT vs. cookies de sessão

Ambas as abordagens preservam um estado autenticado, mas de formas diferentes:

• Cookie de sessão: ID opaco, o servidor usa-o para procurar o estado completo na store de sessão. A revogação é imediata, mas cada pedido custa uma consulta.
• JWT: contém o próprio estado, protegido apenas por assinatura. Sem consultas, perfeito para arquiteturas de microsserviços, mas a revogação antes da expiração requer uma allow/deny list.
• Tamanho: os JWTs costumam ter entre 300 e 1500 bytes. Os IDs de sessão andam pelos 32 bytes. Em muitas chamadas API, o tamanho do JWT acumula-se em largura de banda.
• Storage: os cookies (HttpOnly, Secure, SameSite) são o local de armazenamento mais seguro para o mundo do navegador. O localStorage está exposto a XSS.

Regra prática: mantenha sessões para apps puramente server-side, use JWTs para API gateways e backends mobile, idealmente com tempos de vida curtos e fluxo de refresh-token.

Segurança JWT: o que fazer com `algorithm: none`?

Os JWTs viveram vários bugs espetaculares em bibliotecas nos últimos anos. As maiores armadilhas:

• `alg: none`: várias bibliotecas costumavam aceitar tokens sem assinatura sempre que o header o anunciasse. Solução: nunca permitir `none`, fixe o algoritmo permitido no servidor.
• Confusão HS256/RS256: um atacante assina um token com a public key RSA como secret HMAC, o servidor valida-o como HS256 em vez de RS256, e fica enganado. Defesa: o `alg` permitido é fixado no servidor.
• `kid` injection: o campo `kid` aponta para uma chave, mas se não for sanitized pode levar a path traversal ou SQL injection. Trate o valor como input não confiável.
• Secrets fracos: tokens HS256 com "secret" ou "password" como chave caem por brute force em segundos. Use pelo menos 256 bits aleatórios, idealmente de `crypto.getRandomValues()` ou `/dev/urandom`.
• Lifetime longo: cada JWT emitido é válido até expirar, mesmo depois de o utilizador "sair". Use lifetimes curtos (15 min) mais um fluxo de refresh-token, ou uma deny list para endpoints sensíveis.

As cheatsheets da OWASP e o RFC 8725 (JWT Best Current Practices) são leitura obrigatória.

Como valido um JWT?

Uma validação completa cobre muito mais do que apenas a assinatura. Ordem no código do servidor:

• Interpretar o header, verificar `alg` contra uma allowlist (ex: apenas RS256).
• Verificar a assinatura com a chave que corresponde à configuração do issuer. Com JWKS, use `kid` para o lookup, mas faça whitelist dos seus valores primeiro.
• Verificar claims standard: `iss` corresponde ao issuer esperado, `aud` contém a sua audience, `exp` está no futuro, `nbf` e `iat` estão no passado (com pequena tolerância de clock skew).
• Validar os seus claims personalizados (roles, tenant ID, scopes) contra o seu modelo de negócio.
• Se for necessária revogação antecipada, consultar a deny / logout list.

Confie numa biblioteca estabelecida (jose, jjwt, jsonwebtoken etc.), não em código escrito à mão. A criptografia não é projeto de hobby.

Aloje o seu auth backend na KernelHost

Um JWT issuer e um resource server precisam de um backend fiável e de baixa latência. A KernelHost opera VPS e servidores dedicados próprios em Frankfurt FRA01 com proteção DDoS, IPv4 + IPv6 e uplink de 1 Gbit/s. RTT baixa para utilizadores europeus, preços justos, sem vendor lock-in. Sede da empresa em Viena (AT), datacenter em Frankfurt (DE).

FAQ JWT