JWT
2 tools
Fundamentos de segurança web
A segurança web é a prática de proteger aplicativos web e APIs de acesso não autorizado, violações de dados e ataques. Os aplicativos modernos usam autenticação, autorização e criptografia para impor limites de segurança.
Os JSON Web Tokens (JWT) são o mecanismo de autenticação sem estado dominante no desenvolvimento web moderno. Entender como os JWTs funcionam é essencial para construir APIs e aplicativos seguros.
JSON Web Tokens (JWT)
Um JWT é uma forma compacta e segura para URLs de representar afirmações entre duas partes. Consiste em três partes codificadas em Base64url separadas por pontos.
As três partes de um JWT
Contém metadados sobre o token: o algoritmo de assinatura (alg) e o tipo de token (typ).
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9{
"alg": "HS256",
"typ": "JWT"
}Contém as afirmações: declarações sobre o usuário e metadados adicionais. Os dados do payload NÃO são criptografados, apenas assinados.
eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcxNzIwMDAwMH0{
"sub": "user_123",
"role": "admin",
"exp": 1717200000
}Uma assinatura criptográfica sobre o cabeçalho e payload codificados. Verificar esta assinatura garante que o token não foi adulterado.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cHMACSHA256( base64url(header) + "." + base64url(payload), secret )
Afirmações JWT padrão
A especificação JWT define nomes de afirmações padrão para garantir interoperabilidade:
| Afirmação | Nome | Descrição |
|---|---|---|
| iss | Issuer | Identifica o principal que emitiu o token |
| sub | Subject | Identifica o principal que é o assunto do token (ex: ID do usuário) |
| aud | Audience | Identifica os destinatários para os quais o token é destinado |
| exp | Expiration | Timestamp Unix após o qual o token não deve ser aceito |
| nbf | Not Before | Timestamp Unix antes do qual o token não deve ser aceito |
| iat | Issued At | Timestamp Unix em que o token foi emitido |
| jti | JWT ID | Identificador único para o token, usado para prevenir ataques de replay |
Algoritmos de assinatura
O algoritmo de assinatura é declarado no cabeçalho JWT. Escolher o algoritmo certo é crítico para a segurança:
HS256 / HS384 / HS512Simétrico (HMAC)Usa uma chave secreta compartilhada para assinar e verificar. Simples de implementar mas requer que todos os verificadores conheçam o segredo.
RS256 / RS384 / RS512Assimétrico (RSA)Usa uma chave privada para assinar e uma chave pública para verificar. A chave privada nunca sai do servidor de autenticação.
ES256 / ES384 / ES512Assimétrico (ECDSA)Como RSA mas com chaves menores e assinatura mais rápida. Fornece segurança equivalente com melhor desempenho.
"alg": "none"Sem assinatura — PERIGOSOSem assinatura. Um token com alg:none não tem garantia de integridade e pode ser falsificado por qualquer pessoa.
Fluxos de autenticação
- 1.O usuário envia nome de usuário e senha para o endpoint de login
- 2.O servidor valida as credenciais contra o banco de dados de usuários
- 3.O servidor assina um JWT com as afirmações do usuário e a expiração
- 4.O cliente armazena o JWT (localStorage, cookie ou memória)
- 5.O cliente envia o JWT no cabeçalho Authorization: Bearer para solicitações subsequentes
- 1.O cliente redireciona o usuário para o servidor de autorização com o desafio de código
- 2.O usuário se autentica e autoriza o aplicativo cliente
- 3.O servidor de autenticação redireciona de volta com um código de autorização de uso único
- 4.O cliente troca código + verificador por tokens de acesso e atualização
- 5.O cliente usa o token de acesso para chamadas de API; token de atualização para renovação
Vulnerabilidades JWT comuns
Os JWTs são seguros quando implementados corretamente. Estes são os erros de implementação mais comuns:
Algumas bibliotecas aceitam tokens com alg:none. Um invasor pode modificar o payload e definir alg como none para falsificar qualquer JWT.
Se uma biblioteca espera verificar RS256 mas aceita HS256, um invasor pode assinar um token usando a chave pública como segredo HMAC.
Um JWT sem afirmação exp, ou código que não verifica exp, permite que tokens sejam usados indefinidamente.
Os payloads JWT são codificados em Base64, não criptografados. Nunca armazene senhas ou outros segredos nas afirmações JWT.
JWTs assinados com HMAC com segredos curtos ou previsíveis podem ser quebrados por força bruta offline.
Aceitar JWTs sem verificar a assinatura confia completamente no payload. Sempre verifique a assinatura antes de confiar em qualquer afirmação.
Perguntas frequentes
Os JWTs padrão (JWS) são assinados mas NÃO criptografados. O payload é codificado em Base64url, que é trivialmente reversível.
Os tokens de acesso devem ter vida curta: 5-60 minutos é típico. Use tokens de atualização para obter novos tokens de acesso.
Cookies HttpOnly são a opção mais segura — são inacessíveis ao JavaScript, prevenindo roubo por XSS.
Não sem estado no lado do servidor. Soluções: tempos de expiração curtos, uma lista de bloqueio de tokens (Redis).
Cookies de sessão armazenam um ID de sessão aleatório; o servidor procura os dados da sessão. Os JWTs são autossuficientes — o servidor valida a assinatura sem uma consulta ao banco de dados.
O mínimo: sub (ID do usuário), exp (expiração) e iat (emitido em). Mantenha os payloads pequenos.
RS256 (assimétrico) é melhor para a maioria dos sistemas de produção porque apenas o servidor de autenticação precisa da chave privada.
PKCE é uma extensão do fluxo de código de autorização OAuth2 que previne ataques de interceptação de código. É obrigatório para clientes públicos (SPAs, aplicativos móveis).