Um token JWT, abreviação de JSON Web Token, é um formato compacto para passar declarações (claims) entre duas partes. As aplicações comumente usam JWTs após o login: um servidor emite um token, o cliente o envia em requisições posteriores, e uma API verifica o token antes de permitir o acesso. Um JWT não é um token de criptomoeda, e seu conteúdo não é automaticamente secreto.
Sistemas de contas em finanças, exchanges e serviços Web3 podem usar autenticação baseada em token nos bastidores. Leitores explorando plataformas de ativos digitais podem criar uma conta Tapbit, enquanto desenvolvedores devem tratar cada token de autenticação como uma credencial sensível à segurança.
O que é um Token JWT?
O padrão JWT, RFC 7519, define um formato de declarações compacto projetado para transmissão como um objeto JSON. Uma declaração é uma afirmação como um identificador de usuário, emissor do token, público pretendido ou tempo de expiração. JWTs são frequentemente usados como tokens de acesso, tokens de identidade ou mensagens de curta duração entre serviços.
Pessoas frequentemente dizem “token JWT”, embora o “T” final já signifique token. A repetição é comum e inofensiva. O que importa é entender que JWT descreve um formato, não um sistema de login completo. Autenticação segura também requer políticas corretas de emissão, validação, armazenamento, expiração e revogação.
Como Funciona um JSON Web Token?
Um fluxo de login típico começa quando um usuário envia credenciais válidas. O servidor de autenticação cria um JWT contendo declarações selecionadas e o protege com uma assinatura digital ou código de autenticação de mensagem. O cliente então apresenta o JWT a uma API, frequentemente em um cabeçalho HTTP Authorization usando o esquema Bearer.
A API verifica a assinatura e as declarações necessárias antes de confiar na requisição. Verificações importantes podem incluir o emissor, público, tempo de expiração e o algoritmo esperado pela aplicação. Se a verificação for bem-sucedida, a API usa as declarações para tomar uma decisão de autorização. Se falhar, a requisição deve ser rejeitada.
As Três Partes de um JWT
Um JWT assinado comumente visto tem três seções codificadas em Base64url separadas por pontos:
header.payload.signature
- Header: identifica o tipo de token e o algoritmo de assinatura.
- Payload: contém declarações, como
subpara assunto (subject),isspara emissor (issuer),audpara público (audience) eexppara expiração (expiration). - Signature: permite ao destinatário detectar alterações não autorizadas e verificar o signatário quando a chave correta é usada.
A codificação Base64url não é encriptação. Qualquer pessoa que obtenha um JWT assinado normal geralmente pode decodificar seu cabeçalho e carga útil. Informações sensíveis, portanto, não devem ser colocadas na carga útil, a menos que o sistema use um formato encriptado apropriado e tenha uma necessidade clara para isso.
Exemplo de JWT para Iniciantes
Considere uma API que emite um token após Alice fazer login. Sua carga útil pode identificar Alice como o assunto, nomear o emissor, especificar o público da API e expirar em 15 minutos. Quando Alice solicita seu perfil, a API valida o token e usa a declaração de assunto para localizar a conta correta.
Se alguém alterar a carga útil de um identificador de Alice para o identificador de um administrador, a assinatura não corresponderá mais. Esse é o benefício central de um JWT assinado: a adulteração se torna detectável. Uma assinatura válida, no entanto, não prova que todas as declarações são apropriadas. A API ainda deve confirmar que o token veio do emissor esperado e foi destinado a essa API.
JWT vs Cookies de Sessão vs Chaves de API
| Método | Propósito Típico | Onde o estado reside | Consideração Principal |
|---|---|---|---|
| JWT | Declarações e autorização de API | O token carrega declarações; servidores podem ainda manter estado | Design de validação e revogação |
| Cookie de sessão | Sessão de login do navegador | Geralmente armazenamento de sessão no lado do servidor | Proteções de cookie e CSRF |
| Chave de API | Identificar uma aplicação ou projeto | Servidor mapeia a chave para permissões | Chaves são segredos de longa duração, a menos que rotacionadas |
JWTs não são automaticamente melhores que sessões. Sessões podem tornar a revogação imediata simples, enquanto JWTs podem reduzir consultas repetidas ao banco de dados e funcionar bem em serviços distribuídos. Muitos sistemas combinam ambas as abordagens, como um JWT de curta duração com um registro de token de atualização controlado pelo servidor.
JWTs são Encriptados?
Geralmente não. O JWT familiar de três partes é comumente um objeto JSON Web Signature assinado. A assinatura fornece integridade e autenticidade quando implementada corretamente, mas não esconde a carga útil. JSON Web Encryption é um padrão relacionado que pode fornecer confidencialidade, embora use uma estrutura diferente e adicione complexidade de gerenciamento de chaves.
Essa distinção é importante porque desenvolvedores às vezes colam um JWT em um decodificador e se surpreendem ao ver dados legíveis. Decodificar não é o mesmo que verificar a assinatura com sucesso. Aplicações nunca devem conceder acesso apenas com base em declarações decodificadas.
Riscos Comuns de Segurança de JWT
As Melhores Práticas Atuais para JWT, RFC 8725, do IETF, abordam falhas de implementação que apareceram em sistemas reais. Os maiores problemas geralmente vêm de validação incorreta, em vez do formato básico em si.
- Confusão de algoritmo: aceitar um algoritmo inesperado ou inseguro.
- Verificações de declaração ausentes: ignorar emissor, público, expiração ou outros requisitos da aplicação.
- Roubo de token: expor um token bearer através de logs, scripts, armazenamento inseguro ou transporte desprotegido.
- Chaves fracas: usar segredos adivinháveis ou falhar em rotacionar chaves de assinatura comprometidas.
- Expiração longa: deixar tokens roubados úteis por muito tempo.
- Revogação inadequada: assumir que um token assinado nunca pode precisar de invalidação antecipada.
Melhores Práticas de JWT
As aplicações devem permitir explicitamente apenas os algoritmos que suportam, verificar todas as declarações necessárias e usar regras de validação separadas para diferentes tipos de JWTs. Tokens devem ter curta duração, ser transmitidos apenas via HTTPS e excluídos de URLs e logs rotineiros. Chaves de assinatura precisam de armazenamento seguro, rotação e propriedade clara.
O armazenamento depende da aplicação. Sistemas de navegador podem usar cookies seguros, HttpOnly e SameSite, enquanto clientes móveis ou de backend usam armazenamento protegido apropriado para a plataforma. Nenhuma escolha de armazenamento elimina todas as ameaças, então os desenvolvedores devem considerar juntos cross-site scripting, cross-site request forgery, replay de token e comprometimento do dispositivo.
Conclusão
Um JWT é uma maneira compacta de carregar declarações verificáveis entre sistemas. Seu cabeçalho descreve como ele é protegido, sua carga útil contém declarações e sua assinatura ajuda os destinatários a detectar adulterações. JWTs podem simplificar a autenticação de API, mas apenas quando o destinatário verifica o algoritmo, emissor, público, declarações de tempo e assinatura corretos. Para iniciantes, a regra principal é simples: um JWT é um formato de credencial, não prova de que todo o design de autenticação é seguro.
Perguntas Frequentes
O que significa JWT?
JWT significa JSON Web Token, um formato compacto padronizado para transmitir declarações como JSON.
Qualquer um pode decodificar um JWT?
Qualquer um que tenha um JWT assinado típico pode geralmente decodificar seu cabeçalho e carga útil. A decodificação não verifica a assinatura nem torna as declarações confiáveis.
Um JWT é o mesmo que um token de acesso?
Não. Um token de acesso descreve um propósito, enquanto JWT descreve um formato. Alguns tokens de acesso são JWTs, e outros são strings opacas.
Quanto tempo um JWT deve durar?
Não há uma duração universal. Tokens de acesso são comumente de curta duração, com a vida útil exata baseada no risco do sistema, requisitos de revogação e usabilidade.
Um JWT pode ser revogado?
Sim, mas a revogação requer design adicional, como uma lista negra (denylist), rotação de chaves, versionamento de token ou um sistema de token de atualização gerenciado pelo servidor.
