Entendendo na Prática: o que e JWT

O que e JWT

JWT e um padrão aberto para transmitir informações verificáveis entre partes.

JSON Web Token, ou JWT, e um padrão aberto definido pela RFC 7519 que define uma forma compacta e autocontida de transmitir informações entre partes como um objeto JSON. As informações são verificáveis porque o token e assinado digitalmente. Um JWT assinado com HMAC SHA-256 ou RSA garante que ninguem alterou o conteúdo desde que foi emitido. JWT e amplamente usado em autenticação: após o login, o servidor emite um JWT que o cliente armazena e envia em cada requisição subsequente. O servidor valida a assinatura sem precisar consultar um banco de dados, tornando a autenticação stateless. Isso e um dos maiores beneficios do JWT: escalabilidade horizontal sem necessidade de sessões centralizadas e sem estado compartilhado entre instâncias.

Estrutura do token: header.payload.signature

Um JWT e formado por tres partes separadas por ponto, cada uma em Base64URL.

Um JWT tem o formato xxx.yyy.zzz, onde cada parte e codificada em Base64URL. O Header contem o algoritmo de assinatura como HS256 ou RS256 e o tipo do token. O Payload contem os claims, que são as informações que você quer transmitir: o id do usuário, os papeis, a expiração. A Signature e criada aplicando o algoritmo do header sobre o header mais o payload codificados, usando uma chave secreta. Para validar um JWT, o servidor recalcula a assinatura com a chave e compara com a assinatura do token. Se forem iguais, o token não foi alterado. E fundamental entender que Base64URL e apenas codificação, não criptografia: o payload pode ser lido por qualquer pessoa que tenha o token, sem precisar de nenhuma chave.

Como funciona o fluxo de autenticação

Login retorna um token; o cliente envia o token no header Authorization de cada requisição.

O fluxo típico de autenticação com JWT e simples. O usuário envia email e senha para o endpoint de login. O servidor valida as credenciais, cria um JWT com os dados do usuário e o assina com a chave secreta. O servidor retorna o token para o cliente. O cliente armazena o token, geralmente em localStorage ou cookie httpOnly. A cada requisição subsequente, o cliente envia o token no header Authorization com o prefixo Bearer. O servidor recebe a requisição, extrai o token do header, valida a assinatura, verifica a expiração e extrai os dados do usuário do payload. Sem consultar banco de dados, o servidor sabe quem e o usuário e quais são seus papeis. Esse fluxo stateless e a base da escalabilidade de APIs modernas com múltiplas instâncias.

Claims padrão e customizados

Claims são as informações no payload: alguns são padronizados, outros podem ser customizados.

Claims são os pares chave-valor no payload do JWT. Os claims registrados pelo RFC 7519 incluem: sub que e o identificador do usuário, iss que e quem emitiu o token, aud que e para quem o token e destinado, exp que e o timestamp de expiração, iat que e o timestamp de emissão, e nbf que indica a partir de quando o token e valido. Além dos padronizados, você pode adicionar claims customizados: roles com os papeis do usuário, tenantId, email e nome de exibição. O cuidado e não colocar informações sensíveis como senhas ou dados de cartao no payload, pois ele e apenas codificado, não criptografado. Claims devem ser os dados mínimos necessários para autorizar as requisições sem consultar o banco a cada chamada.

Stateless vs Session

JWT elimina a necessidade de armazenar estado no servidor, mas dificulta a revogação.

A principal diferença entre JWT e sessão e o estado. Com sessão, o servidor armazena o estado da autenticação em banco ou cache. Com JWT, o estado esta no próprio token e o servidor não precisa armazenar nada. Isso tem vantagens claras em escalabilidade: qualquer instância do servidor pode validar o token sem acessar um armazenamento centralizado. O trade-off e a revogação: uma sessão pode ser invalidada imediatamente deletando a entrada no servidor. Um JWT só expira quando atingir o timestamp de expiração. Se um JWT for comprometido, você não pode invalida-lo diretamente sem implementar uma lista negra, o que recuperária parte do overhead do stateful. A solução prática mais adotada e usar tokens de curta duração com refresh tokens para renovação transparente.

Refresh token e rotação

Refresh token renova o access token sem pedir login novamente ao usuário.

Access tokens de curta duração aumentam a segurança, mas obrigar o usuário a fazer login a cada 15 minutos seria inaceitável. O refresh token resolve isso. Ao fazer login, o servidor emite dois tokens: um access token de curta duração e um refresh token de longa duração armazenado de forma segura no servidor. Quando o access token expira, o cliente envia o refresh token para um endpoint específico, e o servidor emite um novo access token. Com refresh token rotation, a cada uso do refresh token, um novo refresh token e emitido e o antigo e invalidado. Isso limita o dano se um refresh token for comprometido: ele só pode ser usado uma vez. O refresh token deve ser armazenado em cookie httpOnly para proteção contra ataques XSS que tentam roubar tokens via JavaScript.

Exemplos em APIs REST

JWT e o padrão de fato para autenticação de APIs REST e microservicos.

Em uma API REST, o JWT flui da seguinte forma: a rota de login com credenciais retorna access_token e refresh_token. Todas as rotas protegidas exigem o header Authorization Bearer com o access token. O middleware de autenticação extrai o token, valida a assinatura com a chave secreta, verifica que a expiração ainda não passou e extrai o userId e os roles do payload. Se o token for inválido ou expirado, retorna 401 Unauthorized. O cliente intercepta o 401, chama a rota de refresh com o refresh token e obtem um novo access token sem interromper a experiência do usuário. Em microservicos, o API Gateway valida o JWT uma única vez e encaminha os dados do usuário em headers para os serviços downstream, que confiam nos headers sem revalidar o token individualmente.

Quando usar JWT

JWT faz sentido para APIs, microservicos e sistemas que precisam escalar horizontalmente.

JWT e a escolha certa quando: você tem uma API REST ou GraphQL; o sistema usa microservicos e precisa propagar identidade entre serviços; a aplicação escala horizontalmente com múltiplas instâncias; você tem clientes mobile ou SPAs que armazenam o token localmente; ou você precisa de autorização stateless para redução de latência. JWT pode não ser a melhor escolha quando: a revogação imediata de tokens e um requisito crítico e você não quer implementar lista negra; a aplicação e um site web tradicional com poucos usuários e servidores fixos; ou a segurança extrema exige que o estado de autenticação seja sempre verificado no servidor, sem possibilidade de token comprometido ainda considerado valido pelo sistema.

Vantagens e cuidados

Stateless e escalabilidade são as vantagens; segurança do segredo e revogação são os cuidados.

Vantagens do JWT: stateless e escalável horizontalmente sem sessões centralizadas; autocontido, o token carrega todas as informações necessárias; padrão aberto amplamente suportado por todas as linguagens e frameworks; e compacto para ser enviado em headers HTTP. Cuidados críticos: nunca armazenar o secret em texto plano ou commitar no repositório git; usar algoritmos seguros como RS256 para produção com múltiplos serviços; definir expiração curta para access tokens; o payload não e criptografado, não colocar dados sensíveis; armazenar refresh tokens em cookie httpOnly para proteção contra XSS; e implementar rotação de refresh tokens para detectar e bloquear uso indevido de tokens roubados.

Resumo

JWT e um padrão robusto para autenticação stateless em APIs modernas.

JWT e formado por header, payload e signature, separados por pontos e codificados em Base64URL. O payload contem claims com informações do usuário. A signature garante que o token não foi alterado. O fluxo de autenticação e direto: login retorna o token, o cliente envia no header Authorization, o servidor valida sem consultar banco. Refresh tokens renovam o access token sem login repetido. O JWT e stateless, escalável e o padrão de fato para APIs REST e microservicos. Os cuidados principais são: proteger o secret, usar expiração curta, não colocar dados sensíveis no payload e implementar refresh token rotation. Com essas boas práticas, JWT e uma solução segura e eficiente para autenticação em sistemas modernos.