# Decodificador e verificador de JWT

> Decodifique o cabeçalho e os claims de um JSON Web Token, leia sua expiração e seus tempos em linguagem clara e verifique uma assinatura HS256/384/512 com um segredo colado. Roda inteiramente no seu navegador.

- Tool: https://ronutz.com/pt-BR/tools/jwt
- Family: Identidade e tokens

---

## O que faz

Cole um JSON Web Token para ler o que há dentro dele e, para um token assinado com HMAC, verificar se sua assinatura é válida. A ferramenta divide o token em suas três partes, decodifica o cabeçalho e os claims, traduz os claims de tempo em datas legíveis e, se você fornecer o segredo, verifica uma assinatura HS256, HS384 ou HS512. Tudo roda no seu navegador; um segredo colado nunca sai dele.

## O formato de um JWT

Um JWT na sua forma compacta usual são três segmentos Base64url unidos por pontos: `cabeçalho.payload.assinatura`. O **cabeçalho** nomeia o algoritmo de assinatura (`alg`) e frequentemente um id de chave (`kid`); o **payload** carrega os claims, um objeto JSON de afirmações sobre o sujeito; e a **assinatura** é calculada sobre os dois primeiros segmentos, de modo que qualquer adulteração deles possa ser detectada. Os claims registrados incluem o emissor (`iss`), o sujeito (`sub`), a audiência (`aud`) e os campos de tempo `iat`, `nbf` e `exp`, que são segundos numéricos desde a época Unix e que a ferramenta apresenta como datas legíveis.

## Decodificar não é verificar

Esta é a coisa mais importante de entender sobre um JWT: o cabeçalho e o payload são apenas codificados em Base64url, não criptografados. Qualquer um que tenha o token consegue lê-los, então um JWT não é lugar para colocar segredos. Decodificar diz o que um token afirma; não diz se essas afirmações são verdadeiras. Só verificar a assinatura contra a chave correta prova que o token foi emitido por quem ele diz e não foi alterado.

## Verificação da assinatura e o algoritmo

HS256, HS384 e HS512 assinam com um HMAC sobre um segredo compartilhado, a mesma construção que a ferramenta de HMAC usa, então este verificador e aquela ferramenta concordam. Como o segredo tanto assina quanto verifica, quem consegue verificar um token assinado com HS também consegue criar um; esse é o compromisso simétrico, e é por isso que serviços que precisam deixar outros verificarem sem poder forjar usam um algoritmo assimétrico como RS256 ou ES256. Uma família conhecida de ataques abusa do campo `alg`, seja definindo-o como `none`, seja enganando um servidor que possui uma chave pública RSA para que a trate como um segredo HMAC; a orientação de boas práticas atuais na RFC 8725 existe para fechar essas brechas, e a versão curta é: sempre confira que o algoritmo é o que você espera.

## Como usar

Cole um token para decodificar seu cabeçalho e seus claims e ler seus tempos em linguagem clara. Para verificar um token assinado com HMAC, cole o segredo compartilhado e a ferramenta confirma se a assinatura corresponde. Se um token está expirado agora é mostrado em relação ao seu relógio atual, sobreposto aos claims de tempo que o decodificador lê.

## Standards and references

- [RFC 7519 - JSON Web Token (JWT)](https://www.rfc-editor.org/rfc/rfc7519) - claims set + registered claim names
- [RFC 7515 - JSON Web Signature (JWS)](https://www.rfc-editor.org/rfc/rfc7515) - compact serialization + signing input
- [RFC 7518 - JSON Web Algorithms (JWA)](https://www.rfc-editor.org/rfc/rfc7518) - alg values (HS256, RS256, ES256, none)
- [RFC 8725 - JWT Best Current Practices](https://www.rfc-editor.org/rfc/rfc8725) - alg confusion + validation guidance

## Related reading

- [Algoritmos de assinatura de JWT: HMAC, RSA e ECDSA](https://ronutz.com/pt-BR/learn/jwt-signing-algorithms.md): Por que o cabeçalho alg de um JWT importa, a diferença entre assinatura simétrica e assimétrica, e como escolher.
- [Anatomia de um JSON Web Token](https://ronutz.com/pt-BR/learn/jwt-anatomy.md): Os três segmentos de um JWT, como a assinatura o torna confiável e por que decodificar um token não é o mesmo que verificá-lo.
- [Armadilhas de segurança em JWT: alg:none, confusão de chave e verificações ausentes](https://ronutz.com/pt-BR/learn/jwt-security.md): O punhado de erros que transforma um verificador de JWT em uma máquina de falsificação, e a validação que um verificador correto deve fazer.
- [As Claims do ID Token, e o Que uma Relying Party Verifica](https://ronutz.com/pt-BR/learn/id-token-claims.md): As claims dentro de um ID token OIDC: as obrigatórias iss, sub, aud, exp e iat; o nonce que impede repetição; azp quando há múltiplas audiências; acr e amr para a força da autenticação; auth_time; e as claims de vínculo at_hash e c_hash, com a validação que uma relying party realiza em cada uma.
- [O fluxo de código de autorização do OAuth 2.0](https://ronutz.com/pt-BR/learn/oauth-code-flow.md): Os quatro papéis, a dança de redirecionar e trocar, e por que o código é trocado por um token no canal de fundo.
- [OIDC vs OAuth 2.0: Autenticação vs Autorização](https://ronutz.com/pt-BR/learn/oidc-vs-oauth.md): Por que o OAuth 2.0 é sobre autorização e o OpenID Connect é sobre autenticação, a diferença entre um access token e um ID token, por que usar OAuth puro como mecanismo de login é um antipadrão conhecido, e como saber qual token é qual.
- [OpenID Connect: identidade sobre o OAuth 2.0](https://ronutz.com/pt-BR/learn/openid-connect.md): Como o OIDC adiciona autenticação à autorização do OAuth, o que é o token de ID e por que o fluxo de código com PKCE é o caminho recomendado.
- [OpenID Connect: Uma Camada de Identidade sobre o OAuth 2.0](https://ronutz.com/pt-BR/learn/oidc-overview.md): O que o OpenID Connect adiciona ao OAuth 2.0, o ID token no centro de tudo, os papéis de relying party e provedor, como o fluxo de código de autorização entrega um ID token, e por que um ID token é apenas um JWT que você pode decodificar e ler.
- [Tokens de acesso, tokens de atualização e tokens de ID](https://ronutz.com/pt-BR/learn/oauth-tokens.md): Três tokens do OAuth e do OpenID Connect que vivem sendo confundidos, para que cada um de fato serve, e por que enviar o errado ao lugar errado é um bug de verdade.
