Um JSON Web Token (JWT) parece uma string longa e aleatoria, mas sao so tres pedacos de dados colados com pontos. O primeiro diz como o token foi montado. O segundo sao os claims - para quem e, quando expira e o que o emissor colocou. O terceiro e uma assinatura que um servidor confiavel pode checar. Este guia percorre cada parte, os claims do dia a dia e a diferenca entre ler um token e confiar nele. Para inspecionar um token de verdade, cole no Decodificador JWT - roda no navegador e nao faz upload.
Resposta rapida
Um JWT e header.payload.signature. Cabecalho e payload sao JSON em Base64URL. O cabecalho quase sempre tem alg e typ. O payload guarda claims como sub, iat e exp mais campos seus. A assinatura e o terceiro segmento. Decodificar mostra esses JSON. Nao prova que o token e autentico - verificar precisa do segredo ou da chave publica num servidor confiavel.
Tres partes unidas por pontos
A RFC 7519 define um JWT compacto como tres segmentos Base64URL separados por ponto. Nao ha wrapper extra, nao ha JSON por fora e em geral nao ha iguais de padding. Se voce parte em . sempre recebe tres strings, mesmo quando a ultima esta vazia (a forma insegura alg none).
- Cabecalho: metadados do token, quase sempre JSON com alg e typ.
- Payload: os claims. E isso que as APIs de fato leem.
- Assinatura: uma tag criptografica sobre cabecalho e payload. Este artigo e a ferramenta tratam isso como bytes opacos.
Qualquer pessoa que saiba escrever JSON pode inventar um cabecalho e um payload e codificar em Base64URL. Por isso as duas primeiras partes sao publicas. Quem interceptar um JWT le esses claims. Dado confidencial nao cabe num JWT a menos que voce tambem cifre (JWE), que e outro formato.
O cabecalho
O cabecalho diz aos verificadores como tratar o token. E um objeto JSON pequeno. Depois de decodificar o primeiro segmento em Base64URL voce em geral ve:
- alg - o algoritmo usado para assinar (ou none). Valores comuns: HS256 (HMAC com segredo compartilhado), RS256 ou ES256 (chaves assimetricas).
- typ - em geral JWT. Alguns emissores omitem.
- kid - id de chave opcional para o servidor escolher a chave publica certa num JWKS.
- cty - tipo de conteudo, raro, quando o payload e um JWT aninhado.
O campo perigoso e alg. Um decodificador mostra o que o token afirma. Um verificador ingenuo que aceita alg none, ou que deixa um atacante trocar RS256 por HS256 e assinar com a chave publica como se fosse um segredo HMAC, aceita tokens forjados. Isso e bug de servidor, nao algo que um decodificador no navegador resolva. Leia alg como dica, nunca como prova.
O payload (claims)
O payload e outro objeto JSON. As specs JWT separam claims registrados (um vocabulario pequeno compartilhado) e nomes privados ou publicos que o seu app define. Timestamps sao NumericDate: segundos desde 1970-01-01 UTC, nao milissegundos.
Claims registrados que voce ve o tempo todo
- iss - emissor. Quem criou o token (uma URL ou o nome do auth server).
- sub - sujeito. O usuario ou servico de que o token fala.
- aud - audiencia. A API ou app que deveria aceitar. Pode ser string ou array.
- exp - expiracao. Recuse o token depois deste tempo Unix.
- nbf - not before. Recuse o token antes deste tempo Unix.
- iat - issued at. Quando o emissor criou.
- jti - id do JWT. Um id unico para revogar ou deduplicar tokens.
Claims customizados
Todo o resto e dado da aplicacao: name, email, role, scope, tenant ou um array de permissoes. E conveniente para APIs e tambem trivial de forjar se voce so decodifica. Um claim role: admin num token colado no decodificador significa que o emissor (ou um atacante) escreveu essa string. Nao e concessao de permissao ate o backend verificar a assinatura e checar iss, aud e exp.
A assinatura
O terceiro segmento nao e JSON. Em HS256 e um HMAC-SHA256 sobre a string ASCII header.payload com um segredo compartilhado. Em RS256 ou ES256 e uma assinatura assimetrica sobre a mesma entrada. O decodificador mostra o texto Base64URL cru para voce comparar tokens; ele nunca recalcula nem valida essa tag. Verificar precisa do segredo ou da chave publica do emissor, e precisa acontecer numa maquina em que voce confia.
Decodificar nao e verificar
Ler o JSON de cabecalho e payload so responde "o que este token afirma?". Um servidor que aceita o token ainda precisa verificar a assinatura, recusar o alg errado, checar exp / nbf / iat e casar iss e aud. O Decodificador JWT e para inspecao e debug, nao para login.
Base64URL, nao Base64 comum
Cabecalho e payload de JWT usam Base64URL (RFC 4648): a mesma codificacao de 6 bits do Base64, mas + vira -, / vira _ e o padding = costuma sumir. Assim o token fica seguro em query strings e headers. Se voce colar um segmento JWT numa ferramenta Base64 generica, restaure os caracteres URL primeiro ou o JSON nao abre. O Codificador / decodificador Base64 e para Base64 comum; a ferramenta JWT ja aplica o alfabeto URL.
Exemplo pratico
O token de demo classico da documentacao JWT decodifica para um cabecalho e um payload minimos. Depois de partir nos pontos e decodificar as duas primeiras partes em Base64URL voce obtem:
- JSON do cabecalho: {"alg":"HS256","typ":"JWT"}
- JSON do payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}
- iat 1516239022 e 2018-01-18 01:30:22 UTC - o token esta anos alem de qualquer exp real se houvesse uma.
- O terceiro segmento e a assinatura HMAC. Olhar para ela nao diz se o segredo estava certo.
Um prefixo Bearer nao faz parte do JWT. Authorization: Bearer eyJ... e convencao de header HTTP. Remova Bearer e o espaco, depois decodifique os tres segmentos. O decodificador da ToolsMinify faz isso por voce.
O que voce pode ler vs o que o servidor precisa checar
Use um decodificador quando estiver depurando. Use um verificador quando estiver autorizando.
- Voce pode ler alg, typ e kid para ver qual chave o emissor pretendia.
- Voce pode ler sub, email ou role para entender uma request que falha.
- Voce pode comparar exp e iat com o relogio para ver se o token envelheceu.
- Um servidor precisa verificar a assinatura com a chave e o algoritmo certos.
- Um servidor precisa recusar tokens com iss ou aud errados, e tokens ainda invalidos ou ja expirados.
- Um servidor precisa tratar cada claim como nao confiavel ate essas checagens passarem.
Erros comuns
- Confiar em claims vistos num decodificador. Qualquer um monta header.payload e deixa uma assinatura lixo.
- Aceitar alg none ou deixar o token escolher o algoritmo de verificacao.
- Colocar senhas, segredos de sessao ou dados pessoais no payload. O payload e legivel para quem tem o token.
- Colar tokens de producao num site aleatorio. Prefira um decodificador no cliente para o token nao sair da maquina.
- Confundir este formato com JWTs cifrados (JWE). Um JWE compacto tem cinco segmentos, nao tres.
Perguntas frequentes
Um JWT e criptografado?
Um JWT assinado padrao (JWS) nao e criptografado. Cabecalho e payload so estao codificados. Quem tem o token le os claims. Tokens cifrados usam JWE e parecem diferentes. Se voce cola um token num decodificador e ve JSON, ele nao era confidencial.
Por que o decodificador nao verifica a assinatura?
Verificar precisa de um segredo ou da chave publica de quem tem a privada. Colocar isso numa pagina publica seria inseguro, e um selo verde de "valido" num site em que voce nao confia ensina a confiar na checagem errada. Decodifique localmente; verifique na sua API.
O que significa alg none?
Significa que o emissor (ou um atacante) marcou o token como nao seguro. O terceiro segmento esta vazio. Um decodificador ainda mostra cabecalho e payload. Uma API de producao deveria recusar alg none, salvo um motivo local e explicito para aceitar tokens sem assinatura.
exp e iat sao em milissegundos?
Nao. NumericDate de JWT sao segundos desde o epoch Unix. Se um claim parece 1.7e12 voce provavelmente esta vendo Date.now() do JavaScript em milissegundos por engano.
Posso remontar um token depois de editar o payload?
Voce pode recodificar o JSON para Base64URL e juntar tres segmentos, mas a assinatura antiga nao vai mais bater. Sem o segredo ou a chave privada do emissor o token novo e forjado. Isso e esperado. Decodificadores servem para ler, nao para emitir tokens de producao.
Onde inspecionar um token com seguranca?
Use uma pagina que decodifica no navegador e nao faz upload da string. O Decodificador JWT da ToolsMinify faz isso. Para o passo a passo, veja Como usar o Decodificador JWT.
Inspecione um token no navegador
Cole um JWT para ver cabecalho, payload e assinatura em secoes legiveis. Nada e enviado:
- Decodificador JWT - parte o token, formata o JSON de cabecalho e payload, copia cada parte.
- Como usar o Decodificador JWT - guia passo a passo da mesma ferramenta.
- Codificador / decodificador Base64 - Base64 comum, nao o alfabeto URL do JWT.
- Gerador de hash - Checksums SHA-256 no navegador. Nao assina JWT.
- Todas as ferramentas de desenvolvimento - o indice completo da categoria.
Decodifique um JWT - gratis
Abra o Decodificador JWT, cole um token e leia o cabecalho e os claims. A assinatura aparece como esta e nunca e verificada. Tudo roda no navegador.