Entendendo tokens JWT

O JWT é um padrão (RFC-7519) de mercado que define como transmitir e armazenar objetos JSON de forma compacta e segura entre diferentes aplicações. Os dados nele contidos podem ser validados a qualquer momento, pois o token é assinado digitalmente.

Ele é formado por três seções: Header, Payload e Signature.

Header

O Header é um objeto JSON que define informações sobre o tipo do token (typ), nesse caso JWT, e o algoritmo de criptografia usado em sua assinatura (alg), normalmente HMAC SHA256 ou RSA.

Payload

O Payload é um objeto JSON com as Claims (informações) da entidade tratada, normalmente o usuário autenticado.

Essas claims podem ser de três tipos:

• Reserved claims: atributos não obrigatórios (mas recomendados) que são usados na validação do token pelos protocolos de segurança das APIs.
  • sub (subject): entidade à quem o token pertence, normalmente o ID do usuário;
  • iss (issuer): emissor do token;
  • exp (expiration): timestamp de quando o token irá expirar;
  • iat (issued at): timestamp de quando o token foi criado;
  • aud (audience): destinatário do token, representa a aplicação que irá usá-lo.

Geralmente os atributos mais utilizados, são: sub, iss e exp.

• Public claims: atributos que usamos em nossas aplicações. Normalmente armazenamos as informações do usuário autenticado na aplicação.
• Private claims: atributos definidos especialmente para compartilhar informações entre aplicações.

Por segurança, recomenda-se não armazenar informações confidenciais ou sensíveis no token.

Signature

A assinatura é a concatenação dos hashes gerados a partir do Header e Payload usando base64UrlEncode, com uma chave secreta ou certificado RSA.

Essa assinatura é utilizada para garantir a integridade do token. No caso, se ele foi modificado e se realmente foi gerado por você.

Isso previne ataques do tipo man-in-the-middle, onde o invasor poderia interceptar a requisição e modificar seu conteúdo, desta forma personificando o usuário com informações falsas. Caso o payload seja alterado, o hash final não será válido, pois não foi assinado com sua chave secreta.

Apenas quem está de posse da chave pode criar, alterar e validar o token.

Resultado final

O resultado final é um token com três seções (header, payload, signature) separadas por “.” – ponto.

Usando o token

Ao fazer login em um serviço de autenticação, um token JWT é criado e retornado para o client. Esse token deve ser enviado para as APIs através do header Authorization de cada requisição HTTP com a flag Bearer, conforme ilustra o diagrama abaixo.

Authorization: Bearer [token]

Em posse do token, a API não precisa ir até o banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → consultar as informações do usuário, pois contido no próprio token JWT já temos suas credenciais de acesso.

Nos próximos artigos mostrarei como criar uma API em ASP.NET↳.NET113 conteúdosNovidades do .NET 9 – o tipo genérico OrderedDictionaryDev (Back & Front) · dez 2024Novidades .NET 10: novas formas de uso do .NET CLIDev (Back & Front) · dez 2025Novidades do .NET 5: implementando um proxy reverso com YARP + ASP.NET 5Dev (Back & Front) · nov 2020Ver tudo em Dev (Back & Front) → Core com autenticação usando JWT.

Espero que tenham gostado, e se ficou alguma dúvida ou caso tenham críticas e sugestões, por favor entrem em contato.

Abraços!

Referências

• RFC 7519 (Json Web Token Specification)
• RFC 2104 (HMAC: Keyed-Hashing for Message Authentication)
• RFC 8017 (RSA Cryptography Specification)
• jwt.io
• Auth0