O que é um JSON Web Token (JWT)?

Um JSON Web Token é um token compacto e seguro para URLs que carrega claims JSON assinadas, permitindo verificar requisições sem sessões no servidor. Esse é o enquadramento da própria RFC 7519 — “um meio compacto e seguro para URLs de representar claims a serem transferidas entre duas partes” — e as duas ideias contidas nele carregam tudo o que vem a seguir: o token contém seus fatos, e uma assinatura torna esses fatos verificáveis por qualquer um que tenha a chave certa, sem banco de dados no caminho.

Principais pontos

Um JWT, decodificado

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiJ1c3ItOGZrMiIsInJvbGUi… . dBjftJeZ4CVP…

header     { "alg": "HS256", "typ": "JWT" }
payload    { "sub": "usr-8fk2",  "role": "editor",
             "iss": "https://api.example.com",  "aud": "example-web",
             "iat": 1767024900,  "exp": 1767025800 }        ← vida de 15 minutos
signature  HMACSHA256( base64url(header) + "." + base64url(payload), secret )

Qualquer um pode DECODIFICAR as duas primeiras partes — Base64Url é empacotamento, não criptografia.
Só quem tem a chave consegue FORJAR a terceira — e esse é o truque inteiro.

O contraste que vale ver em código — a alternativa stateful contra a qual toda decisão de JWT é medida:

// JavaScript / Node.js — Back4app JS SDK
// The stateful contrast: Back4app issues revocable session tokens
const user = await Parse.User.logIn('ada', 'correct-horse-battery');
const token = user.getSessionToken(); // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
await Parse.User.logOut(); // token invalid NOW — no waiting for an exp claim

// Flutter / Dart — Back4app Flutter SDK
// The stateful contrast: Back4app issues revocable session tokens
final user = ParseUser('ada', 'correct-horse-battery', null);
await user.login();
final token = user.sessionToken; // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
await user.logout(); // token invalid NOW — no waiting for an exp claim

// iOS / Swift — Back4app Swift SDK
// The stateful contrast: Back4app issues revocable session tokens
let user = try await User.login(username: "ada", password: "correct-horse-battery")
let token = user.sessionToken // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
try await User.logout() // token invalid NOW — no waiting for an exp claim

// Android / Kotlin — Back4app Android SDK
// The stateful contrast: Back4app issues revocable session tokens
val user = ParseUser.logIn("ada", "correct-horse-battery")
val token = user.sessionToken // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
ParseUser.logOut() // token invalid NOW — no waiting for an exp claim

Como a verificação funciona

Uma precisão que os explicadores pulam: “JWT” nomeia o formato das claims; o que todo mundo de fato passa adiante é um JWS (RFC 7515) — a serialização assinada — enquanto o JWE é o irmão criptografado, para payloads que precisam permanecer ilegíveis. E a verificação são dois trabalhos, não um: checar a assinatura e depois validar as claims — exp e nbf contra o relógio, iss contra sua lista de emissores confiáveis, aud contra o identificador deste serviço. Um token perfeitamente assinado que está expirado, veio do emissor errado ou foi cunhado para outra audiência é um ataque perfeitamente assinado.

Claims: o vocabulário do payload

Mantenha os payloads enxutos por dois motivos: os tokens viajam em toda requisição como headers (cookies estouram perto de 4 KB, e cada claim é banda repetida), e tudo neles é legível para quem tiver o token.

JWT vs. session tokens

A verdade fora de moda com que vários guias de boas práticas agora abrem: para um app renderizado no servidor com um único backend, as sessions do framework são mais simples e mais controláveis — JWTs pagam o próprio custo quando os tokens precisam ser verificados entre serviços ou por partes que não deveriam telefonar para casa a cada requisição.

O problema da revogação, com honestidade

Ser stateless é ser incapaz de revogar — a mesma propriedade, descrita duas vezes. Um token assinado é válido até o exp não importa o que tenha acontecido desde então: logout, troca de senha, banimento da conta. Toda correção reintroduz estado, então escolha o sabor: uma denylist indexada por jti + iss (a construção recomendada pela OWASP) checada a cada requisição — estado pequeno, mas estado; versionamento de chaves, que revoga todo mundo de uma vez; ou a arquitetura padrão — access tokens de vida curta (5–15 minutos) mais refresh tokens revogáveis com rotação: cada refresh emite um novo refresh token e aposenta o anterior, então um token roubado morre no primeiro replay, e o reúso de um token aposentado sinaliza o roubo e mata a família inteira de tokens. A latência de revogação passa a ser igual à vida do access token — que é a verdadeira razão de essas vidas serem curtas.

Escolhendo o algoritmo — e os ataques contra a escolha

A seção de ataques para a qual a RFC 8725 existe, em três frases. alg: "none" é um valor legal de header — bibliotecas que o honram aceitam tokens sem assinatura. O ataque de confusão: um verificador que deixa o header do token escolher o algoritmo pode receber um token “HS256” assinado com a chave RSA pública do servidor usada como secret do HMAC — um valor público usado como privado. Os dois morrem do mesmo jeito: o verificador fixa em configuração os algoritmos e as chaves que aceita e nunca confia no header para escolher.

Onde armazenar JWTs no navegador

O modelo de ameaça, não o folclore: localStorage troca imunidade a CSRF por roubo via XSS, cookies trocam o inverso — e é por isso que o consenso divide o par: access token em memória, refresh token em um cookie endurecido.

Casos de uso comuns

• Autenticação de APIs — o bearer token por trás dos headers Authorization em APIs REST e GraphQL.
• Identidade em microsserviços — um token emitido pelo gateway e verificado de forma independente por cada serviço, sem session store compartilhado.
• ID tokens do OpenID Connect — a asserção de identidade assinada em todo login social — sempre um JWT.
• Handoffs entre sistemas — links assinados, payloads de webhook, concessões de download: claims verificadas por uma parte que não pode te chamar de volta.
• Dicas de autorização stateless — papéis e IDs de tenant carregados em claims, com a verificação autoritativa ainda no servidor.

JWTs ou sessions? Matriz de decisão

Limitações e trade-offs

• A irrevogabilidade é estrutural. Toda mitigação — denylists, vidas curtas, rotação — é uma devolução parcial do estado que você removeu; precifique isso antes de escolher stateless.
• Claims envelhecem. Os papéis são um snapshot da emissão; um admin rebaixado continua admin até expirar. Vidas curtas limitam a janela de defasagem.
• O payload é público. Trate-o como legível pelo usuário e por qualquer ladrão de token — identificadores sim, segredos e PII não.
• Defaults de biblioteca já queimaram muita gente. Fixar algoritmos, validar claims e checar o typ são responsabilidades da sua configuração, não garantias da biblioteca.
• O tamanho se acumula. Cada claim viaja em cada requisição; payloads generosos taxam a banda mobile e podem estourar os limites de cookie.

Tokens no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A escolha da própria plataforma ilustra a matriz de decisão: as sessões de cliente usam session tokens revogáveis, mantidos no servidor — as abas de código acima — então logout, trocas de senha e o encerramento de sessões pelo dashboard têm efeito imediato, sem janela de expiração para esperar. JWTs aparecem onde pertencem: os ID tokens OIDC dos provedores de identidade são verificados no servidor pelos adaptadores de auth durante o login social, e funções de Cloud Code podem cunhar ou verificar JWTs para handoffs com terceiros usando bibliotecas padrão — com o secret de assinatura na configuração do servidor, nunca enviado aos clientes. Stateful onde o controle importa, stateless nas bordas onde a verificação precisa viajar: a arquitetura que este artigo defende, já montada.