JWT (JSON Web Token): Parte I

Fala, meus consagrados! Beleza?

O JWT (JSON Web Token) é um padrão aberto usado para representar informações de forma compacta, segura e verificável entre duas partes. Em sistemas modernos, especialmente em APIs, autenticação federada, microsserviços e aplicações web, o JWT é amplamente utilizado para transportar declarações sobre um usuário, cliente ou sessão, permitindo que o servidor valide essas informações sem precisar consultar o estado da sessão a todo momento.

Para concursos de TI, esse assunto é relevante porque conecta diversos temas cobrados em provas: segurança da informação, autenticação, autorização, APIs REST, OAuth 2.0, OpenID Connect, criptografia, integridade de dados e arquitetura distribuída. Além disso, bancas costumam explorar pegadinhas conceituais, como confundir assinatura com criptografia, ou afirmar de forma errada que o JWT “sempre protege o conteúdo por sigilo”, o que não é verdade.

O JWT é um token textual, codificado em formato compacto, utilizado para transportar um conjunto de informações chamadas de claims. Essas claims representam afirmações sobre uma entidade, como um usuário autenticado, um cliente de sistema ou até permissões associadas a uma requisição.

Na prática, um JWT permite que um sistema envie informações para outro de forma que o destinatário consiga verificar se o conteúdo foi alterado. Essa verificação normalmente ocorre por meio de uma assinatura digital ou de um código de integridade criptográfica. Por isso, o JWT é muito usado em cenários em que a aplicação precisa validar rapidamente um token recebido em requisições HTTP.

Um JWT possui, em geral, três partes, separadas por ponto:

header.payload.signature

Cada uma dessas partes é codificada em Base64Url, o que torna o token apropriado para transporte em cabeçalhos HTTP, URLs e cookies.

O header contém metadados do token, principalmente o tipo e o algoritmo usado. Um exemplo seria:

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

O campo alg informa o algoritmo de assinatura, e o campo typ normalmente indica que o objeto é um JWT.

O payload contém as claims, ou seja, os dados transportados pelo token. Exemplo:

{
    "sub": "1234567890",
    "name": "João Silva",
    "role": "admin",
    "exp": 1712345678
}

Esses dados podem incluir identificação do usuário, perfil, permissões, emissor, público-alvo e prazo de expiração.

O campo signature (assinatura) é usada para garantir a integridade do token. Em termos gerais, ela é produzida a partir do header, do payload e de uma chave secreta ou chave privada, dependendo do algoritmo adotado.

Se o conteúdo for alterado depois da emissão, a assinatura não corresponderá mais, e o token será considerado inválido.

JWT não é sinônimo de criptografia! Esse é um dos pontos mais importantes para provas. Muitos candidatos confundem JWT com “token criptografado”. Isso está errado. O JWT, em sua forma mais comum, é um token assinado, não necessariamente criptografado. Isso significa que seu conteúdo pode ser lido por quem tiver acesso ao token, ainda que não possa ser alterado sem invalidar a assinatura.

Em outras palavras:

• Assinatura garante integridade e autenticidade de origem; e
• Criptografia garante confidencialidade.

Logo, um JWT assinado impede adulteração indevida, mas não impede leitura do conteúdo. Por isso, não se deve armazenar dados sensíveis no payload, como senhas, segredos ou informações sigilosas.

Em relação às informações carregadas no token, as claims são declarações feitas sobre uma entidade. Elas podem ser classificadas em três grupos principais.

Registered claims são claims padronizadas, com nomes conhecidos, como:

• iss (issuer): emissor do token;
• sub (subject): assunto do token, geralmente o identificador do usuário;
• aud (audience): destinatário esperado;
• exp (expiration time): data/hora de expiração;
• nbf (not before): momento a partir do qual o token se torna válido;
• iat (issued at): instante de emissão;
• jti (JWT ID): identificador único do token.

Public claims são claims definidas publicamente, evitando colisões de nomes. Costumam seguir convenções registradas ou namespaces.

Por fim, Private claims são claims personalizadas criadas por acordo entre as partes. Exemplo: role, department, scope ou perfil.

Em provas, é comum a banca afirmar que as claims são “obrigatórias”. Isso também está errado. Nem todas são obrigatórias. A presença de cada claim depende do contexto de uso e das regras da aplicação.

Espero que tenham gostado! 

Forte abraço e até a próxima jornada!

Professor Rogerão Araújo