Autenticacao JWT: como funciona em aplicacoes web

Como funciona a autenticacao JWT em aplicacoes web

A autenticacao JWT (JSON Web Token) e um protocolo stateless para verificar a identidade do usuario em aplicacoes web. Diferente de sessoes baseadas em cookies com armazenamento no servidor, o JWT carrega todas as informacoes necessarias dentro do proprio token, assinado criptograficamente. O fluxo basico: o usuario faz login, o servidor gera um token JWT assinado, o cliente armazena esse token (localStorage, sessionStorage ou cookie httpOnly) e o envia no header Authorization: Bearer <token> em cada requisicao subsequente. O servidor valida a assinatura e a expiracao sem consultar banco de dados, o que reduz latencia e permite escalar horizontalmente sem compartilhamento de estado.

O que e um JWT e qual sua estrutura?

JWT e um formato de token definido pela RFC 7519, composto por tres partes codificadas em Base64URL e separadas por ponto (.): header, payload e signature. O header contem o tipo do token (typ: JWT) e o algoritmo de assinatura (alg: HS256 ou RS256). O payload carrega as claims, declaracoes sobre o usuario e metadados, como sub (identificador do usuario), iat (data de emissa), exp (data de expiracao) e role (nivel de acesso). A signature e gerada aplicando o algoritmo escolhido sobre o header + payload concatenados com uma chave secreta (HMAC) ou par de chaves (RSA/ECDSA). O resultado e uma string como eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U.

Como o JWT e gerado no servidor?

No momento do login, apos validar credenciais (usuario/senha, OAuth, etc.), o servidor cria um objeto JWT com as claims necessarias. O payload minimo recomendado inclui sub, iat, exp e jti (identificador unico do token, para revogacao se necessario). O servidor entao assina o token usando uma chave secreta (HS256) ou sua chave privada (RS256). Tokens assinados com RS256 sao preferiveis em sistemas distribuidos, pois a chave publica pode ser distribuida para outros servicos validarem sem expor a chave privada. O token gerado e retornado ao cliente na resposta HTTP, geralmente no corpo JSON ou em um cookie httpOnly.

Como o cliente armazena e envia o JWT?

O cliente (navegador ou aplicativo mobile) pode armazenar o JWT de tres formas principais: localStorage, sessionStorage ou cookie httpOnly. localStorage persiste o token apos fechar o navegador, mas e vulneravel a XSS (Cross-Site Scripting). sessionStorage limpa o token ao fechar a aba, reduzindo janela de exposicao. Cookie httpOnly com flag Secure e SameSite=Strict oferece maior protecao contra XSS, pois o JavaScript nao consegue ler o cookie diretamente. Para enviar o token, o cliente inclui o header Authorization: Bearer <token> em cada requisicao. Se usar cookie httpOnly, o navegador envia automaticamente se o cookie for configurado com Path apropriado.

Como o servidor valida o JWT em cada requisicao?

Ao receber uma requisicao protegida, o servidor extrai o token do header Authorization ou do cookie. O processo de validacao segue quatro etapas: (1) decodificar as tres partes do JWT; (2) verificar a assinatura usando a chave secreta ou publica correspondente ao algoritmo declarado no header; (3) checar a expiracao comparando exp com o timestamp atual; (4) validar outras claims opcionais, como nbf (not before) e iss (issuer). Se qualquer etapa falhar, o servidor retorna HTTP 401 Unauthorized. Se tudo estiver valido, o servidor extrai as claims do payload e as utiliza para autorizar a requisicao (ex.: verificar role).

Qual a diferenca entre JWT e sessoes tradicionais com cookies?

Sessoes tradicionais armazenam o estado do usuario no servidor (memoria, Redis, banco). O servidor gera um ID de sessao aleatorio, envia ao cliente como cookie, e a cada requisicao busca os dados da sessao no armazenamento. Isso cria dependencia de estado centralizado, para escalar, precisa de sessao compartilhada (sticky sessions ou Redis central). JWT e stateless: o token contem todos os dados, e cada servico pode valida-lo independentemente. A desvantagem do JWT e que tokens roubados nao podem ser revogados facilmente (a menos que se mantenha uma blacklist, que quebra o stateless). Sessoes tradicionais permitem revogacao instantanea simplesmente removendo a sessao do armazenamento.

JWT e seguro? Quais os riscos?

JWT nao e inerentemente seguro, a seguranca depende da implementacao. Os riscos comuns incluem: (1) algoritmo none, se o servidor aceitar tokens sem assinatura, um atacante pode forjar tokens; (2) chave secreta fraca, em HS256, uma chave curta permite brute force; (3) token armazenado em localStorage exposto a XSS; (4) token sem expiracao (exp), nunca expira se nao definido; (5) ataque de repeticao (replay attack), token interceptado pode ser reutilizado ate expirar. Mitigacoes: usar RS256 com chave forte, definir exp curto (15-60 minutos), usar refresh tokens, armazenar em cookie httpOnly com Secure e SameSite, validar sempre o algoritmo esperado, e nunca confiar no token sem verificar assinatura.

O que e refresh token e como usar com JWT?

Refresh token e um token de longa duracao (dias ou semanas) usado para obter novos access tokens JWT sem exigir novo login. O fluxo: o servidor emite dois tokens no login, access token (curto, 15 min) e refresh token (longo, 7 dias). O cliente usa o access token nas requisicoes. Quando o access token expira, o cliente envia o refresh token para um endpoint especifico (/refresh), que valida o refresh token e retorna um novo access token. O refresh token deve ser armazenado de forma segura (cookie httpOnly) e pode ser revogado no servidor (diferente do access token stateless). Isso limita a janela de exposicao do access token sem forcar logins frequentes.

Como implementar logout com JWT?

Como JWT e stateless, simplesmente remove-lo do cliente nao invalida o token, ele ainda e valido ate expirar se um atacante o possuir. Solucoes para logout efetivo: (1) blacklist de tokens no servidor (cache Redis com tempo de expiracao), quebrando parcialmente o stateless; (2) rotacao de chave de assinatura (invalida todos os tokens emitidos antes da troca); (3) usar refresh tokens com revogacao no servidor, e definir access token com expiracao muito curta (1-5 minutos). A abordagem mais pratica em aplicacoes web e combinar access token curto com refresh token revogavel: no logout, remove-se o refresh token do banco e o access token expira em minutos.

Resumo pratico

Autenticacao JWT e um metodo stateless que transfere a responsabilidade de estado para o cliente, permitindo escalabilidade horizontal e reducao de consultas ao banco. A implementacao segura exige atencao a: algoritmo de assinatura forte (RS256), expiracao curta do access token, uso de refresh tokens revogaveis, armazenamento seguro (cookie httpOnly com Secure e SameSite), e validacao rigorosa de todas as claims.

Perguntas frequentes sobre autenticacao JWT

O que significa JWT?

JWT significa JSON Web Token, um padrao aberto (RFC 7519) para transmitir informacoes entre partes como um objeto JSON compacto e autossuficiente. Ele e assinado digitalmente, garantindo que as claims nao foram alteradas.

JWT e mais seguro que sessoes tradicionais?

Nao necessariamente. JWT oferece vantagens de escalabilidade e desempenho, mas e vulneravel a roubo de token e falta de revogacao nativa. Sessoes tradicionais permitem revogacao instantanea. A escolha depende do contexto: aplicacoes distribuidas se beneficiam do JWT; sistemas que exigem controle fino de sessoes se beneficiam de sessoes centralizadas.

Como evitar que um JWT seja roubado?

Use conexao HTTPS obrigatoria, armazene o token em cookie httpOnly com flags Secure e SameSite=Strict, evite localStorage, defina expiracao curta (15-60 min), implemente refresh tokens revogaveis, e nunca inclua dados sensiveis no payload (ele e apenas codificado, nao criptografado).

O que e um ataque de repeticao com JWT?

O ataque de repeticao ocorre quando um token valido e interceptado (ex.: por MITM ou XSS) e reenviado pelo atacante para obter acesso. Como JWT e stateless, o servidor nao detecta que o token ja foi usado. Mitigacao: usar expiracao curta (exp), incluir jti unico com verificacao de uso, e utilizar refresh tokens com rotação.

JWT pode conter dados sensiveis?

Nao. O payload do JWT e apenas codificado em Base64URL, nao criptografado. Qualquer um que possua o token pode decodificar e ler as claims. Dados sensiveis (senhas, dados pessoais, tokens de terceiros) nunca devem ser colocados no payload. Para confidencialidade, use JWE (JSON Web Encryption) que criptografa o payload.

Qual a diferenca entre HS256 e RS256 no JWT?

HS256 (HMAC com SHA-256) usa uma unica chave secreta compartilhada entre emissor e validador. RS256 (RSA com SHA-256) usa par de chaves (privada para assinar, publica para validar). RS256 e recomendado em sistemas distribuidos, pois a chave privada fica apenas no emissor, e qualquer servico pode validar com a chave publica sem comprometer a seguranca.