Decodificador de JWT

Três pedaços de texto unidos por pontos

Depois que você entra num site, o servidor precisa reconhecer você de novo na próxima requisição. Um jeito comum de fazer isso é entregar ao seu navegador um bilhete curto e assinado dizendo “este é o usuário 48213, autorizado a ler pedidos, até as 15h15”. Esse bilhete é um JSON Web Token, ou JWT.

Um JWT parece uma longa sequência aleatória, mas sempre tem o mesmo formato, header.payload.signature.

• O cabeçalho (header) é um pequeno objeto JSON que indica o algoritmo de assinatura (alg) e muitas vezes a chave que foi usada (kid).
• O payload é um objeto JSON de claims, que são afirmações como sub (quem), aud (para qual serviço) e exp (até quando).
• A assinatura (signature) é um selo calculado a partir dos dois primeiros pedaços e de uma chave.

Cabeçalho e payload são escritos em Base64URL, um jeito de escrever bytes com letras, dígitos, - e _ para que sobrevivam a uma passagem por um endereço ou por um cabeçalho HTTP. É também por isso que quase todo token começa com eyJ, que é como {" fica nessa codificação.

Codificado não é criptografado

Base64URL é uma forma de escrita. Não tranca nada, e transformá-la de volta em texto não exige chave nenhuma, que é tudo o que esta página faz. Então um JWT assinado não esconde absolutamente nada. Se o payload contém um endereço de e-mail, um papel ou um ID interno, qualquer um que pegue o token consegue ler, seja uma extensão do navegador, um log de proxy ou uma captura de tela.

O que a assinatura garante é a integridade. Mude um caractere do payload e o selo deixa de bater, então o servidor recusa o token. As pessoas ainda conseguem ler. Só não conseguem reescrever.

O que esta página lê e o que ela aponta

O decodificador remove um Bearer inicial, espaços e quebras de linha, divide o token e mostra o cabeçalho e o payload como JSON formatado. Depois passa pelas claims uma por uma. As três datas, exp, nbf (não antes de) e iat (emitido em), são números de segundos desde 1º de janeiro de 1970. Você as vê no seu fuso horário e em UTC, com uma contagem ao vivo como “válido por mais 12 minutos”.

Você também recebe um comentário sobre o algoritmo. HS256 usa um único segredo compartilhado para assinar e para verificar. RS256, ES256 e EdDSA usam um par de chaves, em que uma chave privada assina e uma chave pública verifica, então os serviços que só verificam tokens não conseguem criá-los.

O que a decodificação não consegue dizer

Esta página não verifica a assinatura. Isso exigiria o segredo ou a chave pública do emissor, e uma página que pede o seu segredo de assinatura é uma página para fechar. Por isso, um token falsificado e um legítimo parecem iguais aqui. Leia o resultado como “isto é o que o token afirma”, nunca como “este token é válido”.

Pelo mesmo motivo, “não expirado” só quer dizer que exp é posterior ao relógio do seu dispositivo. O servidor pode ter revogado o token uma hora atrás.

Se você está escrevendo o lado que recebe, as verificações que contam acontecem no seu código. Aceite só os algoritmos que você espera, verifique a assinatura com uma chave em que já confia e depois compare iss, aud e exp com o que você espera. Use uma biblioteca mantida e nunca decida o caminho com base no alg que o token pede.

Um token ativo é uma credencial

Até expirar, um token bearer funciona para quem o apresentar. Cole um token de produção num site e você o entregou a esse site, a menos que a decodificação aconteça no seu navegador. Aqui é o caso. Nenhuma requisição leva o token, ele não é escrito na barra de endereços e não é salvo no armazenamento do navegador. Você não precisa acreditar na nossa palavra: observe a aba Rede (Network) das ferramentas de desenvolvedor, ou carregue a página e fique offline antes de colar.

Mesmo assim, o hábito mais seguro é depurar com tokens de uma conta de teste ou com tokens expirados. Se um token real for parar num chat, num chamado ou num log público, saia da conta em todos os lugares ou peça ao emissor para revogá-lo.