Decodificador JWT

Um JSON Web Token (JWT) é formado por três segmentos codificados em Base64URL e unidos por pontos: um header que descreve o algoritmo, um payload com as claims e uma assinatura calculada sobre os dois primeiros. O header e o payload não são criptografados, apenas codificados, então qualquer pessoa que tenha o token consegue lê-los. É exatamente isso que esta ferramenta faz, e nada além disso.

Como funciona

Cole um token. A ferramenta o divide nos dois pontos, decodifica cada um dos dois primeiros segmentos de Base64URL (o alfabeto com - e _, sem padding, como exige a RFC 7515) para UTF-8 e interpreta o resultado como JSON. O header e o payload aparecem formatados, cada um com seu botão de copiar. O terceiro segmento é exibido como está, porque são os bytes brutos da assinatura, e não JSON.

Se o payload tiver as claims de tempo padrão, elas são exibidas como datas locais: iat (emitido em), nbf (não válido antes de) e exp (expira em), todas timestamps Unix em segundos. O indicador no topo compara exp com o relógio do seu dispositivo; um token é considerado expirado quando o horário atual chega a esse instante ou o ultrapassa. Nenhum indicador aparece quando não há uma claim exp numérica.

Falhas comuns: um token com outro número de segmentos (um JWE, que é criptografado, tem cinco), um segmento que não é Base64URL válido ou um segmento que, decodificado, não resulta em JSON. Cada caso gera uma mensagem específica.

A decodificação acontece no seu navegador e o token nunca é transmitido. Mesmo assim, um token é uma credencial bearer: quem o tiver pode agir em nome do sujeito do token até ele expirar. Prefira decodificar tokens de um ambiente de teste e nunca cole um segredo de assinatura ou uma chave privada em página nenhuma da web.

O que significa "não verificada"

A assinatura prova que o token foi emitido por quem detém a chave de assinatura e que não foi alterado desde então. Conferi-la exige a chave: o segredo compartilhado, nos algoritmos HMAC como HS256, ou a chave pública do emissor, no RS256, no ES256 e nos demais algoritmos assimétricos. Esta ferramenta não tem nenhuma das duas, então não tem como dizer se um token é autêntico. Um token que decodifica sem erros e não expirou ainda pode ser forjado, revogado ou emitido para outra audiência.

A verificação é papel do servidor, com a chave obtida no endpoint JWKS do emissor e o header alg checado contra uma allow-list. Aceitar qualquer algoritmo que o header indicar é a vulnerabilidade clássica de JWT: um atacante define alg como none ou troca um token RSA por um HMAC assinado com a chave pública.

Lendo as claims

Além das claims de tempo, procure iss (quem emitiu), sub (de quem se trata), aud (quem deve aceitá-lo) e jti (um ID único para revogação). Access tokens de servidores OAuth 2.0 costumam acrescentar scope ou roles; ID tokens do OpenID Connect acrescentam campos de perfil como email e name, além de nonce. Claims personalizadas são comuns, mas cada byte do payload viaja em toda requisição, então quanto mais enxuto o token, melhor.

Equivalente na linha de comando

O jq consegue decodificar o payload diretamente, depois que o segmento recebe padding até um múltiplo de quatro caracteres:

TOKEN='eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDAwMDAwMDB9.sig'
printf '%s' "$TOKEN" | cut -d. -f2 | tr '_-' '/+' | awk '{ while (length($0) % 4) $0 = $0 "="; print }' | base64 -d | jq .

Saiba mais

Protegendo APIs REST com JWT aborda a emissão, a validação e a rotação de tokens, incluindo o ataque de confusão de algoritmo mencionado acima. Os tokens em si vêm dos fluxos descritos em OAuth 2.0, e os ID tokens especificamente do OpenID Connect. O conversor de timestamp converte qualquer valor de claim que o decodificador ainda não exiba como data, e o gerador de hash mostra a primitiva SHA-256 sobre a qual as assinaturas HS256 são construídas.