Decodificador de JWT
Cole um JWT (JSON Web Token) para decodificar instantaneamente o cabeçalho e o payload, incluindo a verificação da data de expiração (exp). Nenhuma verificação de assinatura é realizada e nenhuma chave secreta é necessária.
Principais Registered Claims (declarações registradas)
| Claim | Nome | Descrição |
|---|---|---|
| iss | Issuer (emissor) | String ou URL que identifica a entidade que emitiu o token. |
| sub | Subject (assunto) | A entidade à qual o token se refere (geralmente um ID de usuário). |
| aud | Audience (destinatário) | Identificador do destinatário ou da API para a qual o token se destina. |
| exp | Expiration Time (expiração) | Momento (em segundos Unix) a partir do qual o token não deve mais ser aceito. |
| nbf | Not Before (não antes de) | Momento (em segundos Unix) antes do qual o token não deve ser aceito. |
| iat | Issued At (emitido em) | Momento (em segundos Unix) em que o token foi emitido. |
| jti | JWT ID | Identificador único do token, frequentemente usado para detectar ataques de repetição (replay). |
Dicas
- O JWT que você cola é processado inteiramente em JavaScript no seu navegador e nunca é enviado aos servidores do toolbase.cc, então quaisquer dados pessoais ou de autenticação contidos no token permanecem privados.
- Um JWT é uma string Base64URL composta por três partes — cabeçalho, payload e assinatura — separadas por pontos. O cabeçalho e o payload são texto simples que qualquer pessoa pode decodificar (Base64 é uma codificação, não uma criptografia), portanto nunca inclua informações sensíveis, como senhas, no payload.
- Se uma requisição de API falhar com erro 401 porque o token expirou, verificar o valor da claim
expcom esta ferramenta costuma ser a forma mais rápida de confirmar a causa. - O algoritmo de assinatura pode ser verificado no cabeçalho
alg. Implementações que aceitamalg: nonesão vulneráveis ao conhecido ataque "alg=none" de JWT, portanto o servidor deve sempre restringir explicitamente os algoritmos permitidos.
Perguntas frequentes
exp seja anterior ao horário atual, geralmente retornando um erro 401 Unauthorized. Nesse caso, é necessário obter um novo token, por exemplo usando um refresh token.
Curiosidade — Como o JWT viabiliza a "autenticação sem estado"
O JWT (JSON Web Token) foi padronizado pelo IETF como RFC 7519 em 2015. A autenticação tradicional baseada em sessão exigia que o servidor mantivesse uma tabela relacionando IDs de sessão a dados do usuário, mas o JWT embute a própria informação do usuário dentro do token e usa uma assinatura para detectar adulterações. Isso permite que o servidor verifique o estado de autenticação sem manter um armazenamento de sessões, abordagem conhecida como "autenticação sem estado", motivo pelo qual os JWTs são amplamente usados em sistemas distribuídos e microsserviços que abrangem múltiplos servidores.
A estrutura de um JWT é formada por três partes — "cabeçalho.payload.assinatura" — cada uma codificada em Base64URL e unidas por pontos. O ponto crucial é que o cabeçalho e o payload são apenas codificados, não criptografados. Qualquer pessoa pode decodificá-los e ler seu conteúdo, portanto um JWT garante que os dados não foram adulterados, não que seu conteúdo permaneça em sigilo. Caso seja necessário manter informações confidenciais, deve-se usar uma especificação separada que adiciona criptografia de fato, chamada JWE (JSON Web Encryption).
Os esquemas de assinatura se dividem basicamente em duas categorias: os baseados em HMAC (como HS256), em que remetente e destinatário compartilham a mesma chave secreta, e os de criptografia de chave pública (como RS256 e ES256), em que uma chave privada assina o token e uma chave pública o verifica. Desde que o JWT foi adotado como formato dos tokens de acesso e de ID do OAuth 2.0 e do OpenID Connect, ele se tornou o formato padrão de fato para a infraestrutura de autenticação na web.