O que é JWT?

O que é JWT e por que ele existe

Quando falamos de tokens em aplicações web, uma dúvida aparece logo de cara. Então você está me dizendo que eu vou armazenar um token em um local onde o usuário, ou outra pessoa, pode ir lá e visualizar?

Isso mesmo. Os tokens são como chaves de acesso, com informações e uma duração, ou seja, se alguém obtiver o seu token, pode se passar por você.

Por isso, a segurança física é a primeira e mais importante etapa que temos. Se alguém tem acesso ao seu navegador, fisicamente ou remotamente, essa pessoa consegue ver o seu token.

Na verdade, esse seria o menor dos seus problemas. Afinal, os dados de navegação ficam armazenados localmente, e todas as suas sessões estão em arquivos no seu computador.

Basta alguém copiar esses arquivos da sua máquina para a dele e pronto, ele estará logado com todas as suas sessões. Por esse motivo, sempre recomendamos não clicar em links suspeitos, já que uma simples cópia expõe todas as suas informações.

Voltando aos tokens, você pode armazenar uma chave e um valor no Local Storage do navegador. Nesse caso, o ideal é que o conteúdo não fique legível à primeira vista.

Dessa forma, quem pegar o seu token não verá nada além de uma sequência de caracteres como esta:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Como esse processo é comum entre aplicações e APIs, criou-se um padrão chamado JWT, que se pronuncia "jót". A sigla vem de JSON Web Token.

Em outras palavras, o JWT é um formato compacto e seguro para URLs que transporta afirmações, chamadas de claims, entre duas partes. Essas claims ficam em um objeto JSON, protegido por uma assinatura digital.

A estrutura de um JWT

Ao decodificar o token acima, temos como resultado os seguintes objetos JSON:

{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Se você notar, o token usa pontos para separar suas regiões. Assim, ele se divide em três partes principais: header, payload e assinatura.

Um ponto importante precisa ficar claro desde já. O header e o payload não são criptografados, e sim codificados em Base64Url, um formato que qualquer pessoa consegue reverter.

Por isso, o JWT protege a integridade dos dados, mas não o sigilo. Quando o conteúdo precisa ser secreto, existe uma variante chamada JWE, que de fato criptografa o token.

{
  "alg": "HS256",
  "typ": "JWT"
}

// eyJhbGciOiJIUzM4NCIsInR5cCI6IkpXVCJ9
{
  "alg": "HS384",
  "typ": "JWT"
}

// eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

// eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsInByZW1pdW0iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "premium": true,
  "iat": 1516239022
}

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  'MY SECRET KEY'
)

O que é JWT na prática: visualizando e alterando um token

Então quer dizer que, além de salvar o token, eu ainda posso visualizar o conteúdo dele? Sim, sites como o jwt.io permitem visualizar tudo o que um token contém.

Indo além, o jwt.io permite alterar o conteúdo de um token e adicionar informações extras. Você também pode fazer isso manualmente, já que basta decodificar, editar e codificar de novo.

Isso significa que eu posso pegar o token abaixo, gerado para mim, que diz que eu só tenho o perfil student:

{
  "name": "André Baltieri",
  "roles": ["student"],
  "iat": 1516239022
}

Em seguida, adiciono o perfil admin:

{
  "name": "André Baltieri",
  "roles": ["student", "admin"],
  "iat": 1516239022
}

Agora eu tenho um novo token, aparentemente com acesso de administrador:

Entendendo os payloads e a assinatura

Muita calma nessa hora! É possível sim mudar um token, mas para gerar uma assinatura válida é necessária a chave secreta, que somente o servidor deve conter.

Se alguém assinar o token com qualquer outra chave, diferente daquela usada na emissão, a validação falha. É isso que torna os tokens seguros contra alterações.

Então não importa se alguém alterou o token no cliente ou no meio do caminho. Se ninguém assinar o token novamente com a chave correta, o servidor vai considerá-lo inválido.

Man in the middle: existe um ataque comum chamado "homem no meio", que intercepta a comunicação entre o cliente e o servidor para roubar ou modificar informações.

A assinatura impede a modificação silenciosa, mas não impede o roubo. Por isso, sempre trafegue tokens sobre HTTPS, que protege o canal entre as partes.

Outro cuidado importante envolve o campo alg. O servidor nunca deve aceitar tokens com alg igual a none nem deixar que o próprio token escolha o algoritmo de validação.

using System.Security.Claims;
using System.Text;
using Microsoft.IdentityModel.JsonWebTokens;
using Microsoft.IdentityModel.Tokens;

// A chave precisa ter pelo menos 256 bits (32 bytes) para HS256
var secret = "a-very-long-secret-key-with-at-least-32-bytes";
var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(secret));

var handler = new JsonWebTokenHandler();

var token = handler.CreateToken(new SecurityTokenDescriptor
{
    Subject = new ClaimsIdentity([
        new Claim("sub", "1234567890"),
        new Claim("name", "John Doe")
    ]),
    Expires = DateTime.UtcNow.AddHours(2),
    SigningCredentials = new SigningCredentials(key, SecurityAlgorithms.HmacSha256)
});

// A validação confere assinatura e expiração
var result = await handler.ValidateTokenAsync(token, new TokenValidationParameters
{
    ValidateIssuer = false,
    ValidateAudience = false,
    IssuerSigningKey = key
});

Console.WriteLine(result.IsValid);

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022 👈
}

Como o JWT funciona no fluxo de autenticação

Até aqui olhamos o token de forma isolada. Agora vale ver como ele participa de uma autenticação completa entre o front-end e a API.

Primeiro, o usuário informa suas credenciais em uma tela de login. Em seguida, o front-end envia esses dados para um endpoint de autenticação da API.

O servidor confere usuário e senha no banco de dados. Se estiver tudo certo, ele monta as claims, define a expiração e assina o token com a chave secreta.

Então, a API devolve o token para o cliente, que o guarda no navegador ou no aplicativo. A partir desse momento, o usuário não precisa enviar a senha de novo.

Em cada requisição seguinte, o cliente envia o token no cabeçalho HTTP, neste formato:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Por fim, a API recalcula a assinatura, confere a expiração e lê as claims. Com base nelas, decide se o usuário pode ou não acessar aquele recurso.

Repare que o servidor não precisou consultar nenhuma sessão armazenada. Tudo o que ele precisa para validar a requisição está no próprio token e na chave que ele guarda.

JWT ou sessão no servidor

Essa característica stateless é a grande vantagem do JWT. Como a API não guarda estado de sessão, fica mais simples escalar horizontalmente e distribuir a carga entre várias instâncias.

Além disso, o mesmo token pode valer para vários serviços que confiam no mesmo emissor. Por isso, o padrão aparece com frequência em arquiteturas de microsserviços e em provedores de identidade.

Por outro lado, essa mesma característica traz um desafio. Uma vez emitido, o token continua válido até expirar, mesmo que o usuário faça logout ou tenha o acesso bloqueado.

Para contornar isso, as equipes costumam usar tokens de vida curta. Também é comum manter uma lista de tokens revogados, consultada pelo identificador da claim jti.

Já a sessão tradicional guarda o estado no servidor e entrega ao navegador apenas um identificador. Nesse caso, revogar o acesso é imediato, mas a aplicação precisa compartilhar essas sessões entre as instâncias.

Não existe resposta única para todos os cenários. Em geral, APIs consumidas por aplicativos e SPAs se beneficiam do JWT, enquanto aplicações web tradicionais funcionam bem com sessões e cookies.

Boas práticas de segurança com JWT

Depois de entender o que é JWT, vale reunir os cuidados em uma lista objetiva. Eles evitam a maioria dos problemas que aparecem em produção.

• Use sempre HTTPS para trafegar tokens.
• Guarde a chave de assinatura fora do código e troque-a periodicamente.
• Defina exp e valide emissor, público e assinatura em toda requisição.
• Não coloque dados sensíveis no payload.
• Rejeite tokens com algoritmo none ou com algoritmo diferente do esperado.
• Proteja o front-end contra XSS, já que scripts maliciosos conseguem ler o Local Storage.

Para uma visão mais ampla sobre o tema, confira as boas práticas de segurança em APIs ASP.NET Core. Lá, o JWT aparece ao lado de outras camadas de proteção.

Conclusão

Neste artigo, entendemos o que é JWT e como ele funciona. Vimos como o servidor cria os tokens, quais informações eles contêm e por que a assinatura impede alterações.

Também vimos que o payload é legível por qualquer pessoa, por isso ele nunca deve carregar dados sensíveis. Além disso, um tempo de vida bem definido limita o estrago caso alguém roube um token.

Com esses fundamentos, fica muito mais fácil configurar autenticação em qualquer stack. Afinal, o padrão é o mesmo, seja em .NET, Node.js ou qualquer outra plataforma.

FAQ

JWT é criptografado?

Não por padrão. O header e o payload são apenas codificados em Base64Url, e a assinatura garante integridade, não sigilo.

Qual a diferença entre iat e exp?

A claim iat registra quando o token foi emitido. Já a claim exp define o momento em que ele deixa de ser aceito.

Onde devo guardar o JWT no navegador?

Local Storage é simples, mas fica exposto a ataques XSS. Cookies com HttpOnly, Secure e SameSite reduzem esse risco.

Alguém pode alterar meu token?

Pode alterar o conteúdo, mas sem a chave secreta não consegue gerar uma assinatura válida. Assim, o servidor rejeita o token adulterado.

HS256 ou RS256?

HS256 usa uma única chave secreta compartilhada. RS256 usa um par de chaves e facilita a validação por vários serviços sem expor a chave de assinatura.