JWT (JSON Web Token, RFC 7519) é um formato compacto e autocontido para representar claims (afirmações) entre duas partes. Na forma mais comum (JWS — assinatura), o token tem três segmentos separados por ponto: header, payload e assinatura, cada um em Base64URL.

Estrutura rápida

  1. Header — normalmente {"alg":"HS256","typ":"JWT"} indicando algoritmo e tipo.
  2. Payload — JSON com claims como sub (sujeito), iat (emitido em), exp (expiração), iss (emissor), aud (audiência) e claims privados da aplicação.
  3. Signature — bytes que provam integridade: quem possui a chave secreta (HMAC) ou privada (RSA/ECDSA) pode ter gerado aquele token.

Qualquer um o payload decodificando Base64; a assinatura impede alteração sem a chave correta, mas não criptografa dados sensíveis no payload (use JWE ou TLS + tokens opacos se precisar confidencialidade).

Para que serve

  • Sessões stateless após login (com refresh token separado em muitos desenhos).
  • Propagação de identidade entre microserviços com confiança na origem.
  • APIs B2B com credencial de curta duração.

O que JWT não é

  • Não substitui autorização fina — ainda precisa checar papéis no recurso.
  • Não armazena segredos em claro no payload.
  • Não elimina revogação — tokens longos exigem lista de negação, rotação de chaves ou duração curta.

Algoritmos comuns

  • HS256 — HMAC-SHA256 com segredo compartilhado; simples, mas a mesma chave assina e verifica.
  • RS256 / ES256 — par de chaves assimétricas; serviço emissor assina com privada, consumidores verificam com pública (via JWKS em cenários modernos).

Detalhes operacionais em JWT: HS256, RS256 e ES256.

Base64 e JWT

As partes usam alfabeto URL-safe; veja Base64 para entender padding e diferenças do Base64 clássico.

Experimentar

Gere tokens de teste, edite claims, veja timeline de exp e valide assinaturas com Web Crypto no navegador.