Decodificador JWT

O JWT chegou como resposta a um problema real que o crescimento das SPAs e dos microserviços criou no início dos anos 2010. Antes dele, o modelo padrão de autenticação na web era baseado em sessões do lado do servidor: o servidor guarda um registro de quem está logado em memória, banco de dados ou Redis, e o navegador recebe um cookie com o ID da sessão. Isso funciona bem num servidor único, mas em arquiteturas distribuídas com múltiplas instâncias você precisa de sessões compartilhadas, sticky sessions ou um cache centralizado. Mike Jones, John Bradley e Nat Sakimura formalizaram o JWT no RFC 7519 em 2015, mas o conceito circulava desde 2010 no contexto do OAuth 2.0 — o protocolo de autorização que o Google, Facebook e Twitter usavam para permitir login em sites de terceiros.

A estrutura de um JWT são três partes separadas por ponto, cada uma em Base64URL: cabeçalho, payload e assinatura. O cabeçalho indica o algoritmo — HS256 usa HMAC com SHA-256 e chave simétrica compartilhada; RS256 usa RSA com SHA-256 e par de chaves assimétrico. O payload carrega os claims padrão: sub para o ID do usuário, exp para o timestamp de expiração, iat para a emissão e iss para o emissor. A assinatura garante que o token não foi adulterado, mas não criptografa o payload — qualquer pessoa pode decodificar um JWT em Base64, só não pode criar um token válido sem a chave. Uma vulnerabilidade histórica: algumas bibliotecas aceitavam tokens com o algoritmo declarado como none, pulando a verificação de assinatura completamente.

O debate sobre usar JWT para autenticação de aplicações web é mais rico do que parece. A vantagem principal é a natureza stateless: o servidor não precisa consultar banco de dados a cada requisição, genuinamente útil em microserviços onde dezenas de serviços precisam verificar autenticação. O problema central é que você não pode invalidar um token antes de ele expirar — se um usuário faz logout ou é comprometido, o token continua válido até exp. A solução usual, uma lista negra de tokens revogados no Redis, reconstrói exatamente o estado centralizado que você estava tentando evitar. Para aplicações web tradicionais com um servidor, tokens opacos com sessões no servidor costumam ser a escolha mais simples e segura. JWT brilha em OAuth e OIDC para login federado e em tokens de curta duração entre microserviços.

JWT arrived as a response to a real problem that the growth of SPAs and microservices created in the early 2010s. Before it, the standard authentication model on the web was based on server-side sessions: the server keeps a record of who is logged in in memory, a database, or Redis, and the browser receives a cookie with the session ID. This works well on a single server, but in distributed architectures with multiple instances you need shared sessions, sticky sessions, or a centralized cache. Mike Jones, John Bradley, and Nat Sakimura formalized JWT in RFC 7519 in 2015, but the concept had been circulating since 2010 in the context of OAuth 2.0 — the authorization protocol that Google, Facebook, and Twitter used to allow login on third-party sites.

A JWT's structure consists of three dot-separated parts, each Base64URL-encoded: header, payload, and signature. The header declares the algorithm — HS256 uses HMAC with SHA-256 and a shared symmetric key; RS256 uses RSA with SHA-256 and an asymmetric key pair. The payload carries standard claims: sub for the user ID, exp for the expiration timestamp, iat for the issued-at time, and iss for the issuer. The signature ensures the token was not tampered with, but does not encrypt the payload — anyone can decode a JWT payload from Base64, they simply cannot create a valid token without the key. A historically notable vulnerability: some libraries accepted tokens with the algorithm declared as none, skipping signature verification entirely.

The debate around using JWT for web application authentication is richer than it appears. The main advantage is the stateless nature: the server does not need to query a database on every request, genuinely useful in microservices where dozens of services need to verify authentication. The central problem is that you cannot invalidate a token before it expires — if a user logs out or is compromised, the token remains valid until exp. The usual solution, a revoked token blacklist in Redis, reconstructs exactly the centralized state you were trying to avoid. For traditional web applications with a single server, opaque tokens with server-side sessions are usually the simpler and safer choice. JWT shines in OAuth and OIDC for federated login and in short-lived tokens between microservices.

El JWT llegó como respuesta a un problema real que el crecimiento de las SPAs y los microservicios creó a principios de los años 2010. Antes de él, el modelo estándar de autenticación en la web se basaba en sesiones del lado del servidor: el servidor guarda un registro de quién está conectado en memoria, base de datos o Redis, y el navegador recibe una cookie con el ID de sesión. Esto funciona bien con un único servidor, pero en arquitecturas distribuidas con múltiples instancias necesitas sesiones compartidas, sticky sessions o una caché centralizada. Mike Jones, John Bradley y Nat Sakimura formalizaron el JWT en el RFC 7519 en 2015, aunque el concepto circulaba desde 2010 en el contexto de OAuth 2.0 — el protocolo de autorización que Google, Facebook y Twitter usaban para permitir el inicio de sesión en sitios de terceros.

La estructura de un JWT son tres partes separadas por punto, cada una en Base64URL: cabecera, payload y firma. La cabecera declara el algoritmo — HS256 usa HMAC con SHA-256 y clave simétrica compartida; RS256 usa RSA con SHA-256 y par de claves asimétrico. El payload lleva los claims estándar: sub para el ID del usuario, exp para el timestamp de expiración, iat para la emisión e iss para el emissor. La firma garantiza que el token no fue alterado, pero no cifra el payload — cualquiera puede decodificar un JWT en Base64, simplemente no puede crear un token válido sin la clave. Una vulnerabilidad históricamente conocida: algunas bibliotecas aceptaban tokens con el algoritmo declarado como none, omitiendo por completo la verificación de firma.

El debate sobre usar JWT para autenticación de aplicaciones web es más rico de lo que parece. La ventaja principal es la naturaleza stateless: el servidor no necesita consultar la base de datos en cada petición, lo que es genuinamente útil en microservicios donde docenas de servicios necesitan verificar la autenticación. El problema central es que no puedes invalidar un token antes de que expire — si un usuario cierra sesión o es comprometido, el token sigue siendo válido hasta exp. La solución habitual, una lista negra de tokens revocados en Redis, reconstruye exactamente el estado centralizado que intentabas evitar. Para aplicaciones web tradicionales con un único servidor, los tokens opacos con sesiones del lado del servidor suelen ser la opción más simple y segura. El JWT brilla en OAuth y OIDC para el inicio de sesión federado y en tokens de corta duración entre microservicios.