Decodificador e codificador JWT
As falhas de autenticação JWT são opacas. Uma resposta 401 não diz nada – você não pode ver se o token expirou, se a reivindicação do público está errada, qual algoritmo foi usado ou se a carga útil foi adulterada. A maioria das ferramentas online apenas decodifica: elas não podem codificar um novo token, verificar uma assinatura ou gerar chaves – e muitas enviam seus tokens para servidores externos.
Esta ferramenta lida com todas as quatro operações JWT em um só lugar – decodificar, codificar, verificar e gerar chaves – com suporte total para algoritmos HMAC (HS256, HS384, HS512), RSA e RSA-PSS. Inspecione as declarações de qualquer token sem uma chave de assinatura, codifique novos tokens com cargas personalizadas, verifique assinaturas em relação a segredos ou chaves públicas e gere chaves aleatórias criptograficamente seguras e prontas para produção. Tudo é executado no seu navegador por meio da API Web Crypto – nenhum token, chave ou carga sai do seu dispositivo.
Decodificar JWT
Codificar JWT
Verifique a assinatura JWT
Gerador de chave secreta JWT
O que é um decodificador JWT?
Um decodificador JWT – também chamado de analisador, depurador ou visualizador JWT – é uma ferramenta que divide um JSON Web Token em suas três partes: cabeçalho, carga útil e assinatura, exibindo cada uma como JSON legível. Um codificador JWT faz o inverso: pega um cabeçalho, uma carga útil e uma chave de assinatura e produz um token compacto assinado. JSON Web Token (JWT, pronunciado "jot") é um padrão aberto definido pela IETF na RFC 7519 para transmitir declarações verificadas entre duas partes como uma string compacta e segura para URL.
JWTs são a base da autenticação sem estado na arquitetura web moderna. Depois que um usuário faz login, o servidor de autorização emite um JWT assinado contendo declarações verificadas – um ID de usuário, função, prazo de validade – e o retorna ao cliente. O cliente anexa esse token a cada solicitação de API subsequente. O servidor verifica a assinatura digital sem consultar um armazenamento de sessão, o que torna o sistema rápido e escalável entre microsserviços. Na maioria dos sistemas, um token de acesso de curta duração e um token de atualização de vida mais longa são emitidos juntos, o token de acesso carrega as declarações JWT, enquanto o token de atualização é usado para solicitar um novo após o vencimento.
Os dois protocolos mais comuns que dependem de JWTs são OAuth 2.0 (autorização) e OpenID Connect (OIDC, identidade e autenticação). Em ambos, os JWTs carregam declarações padronizadas definidas na RFC 7519. Google, Microsoft, Okta e Auth0 emitem tokens de ID OIDC como JWTs.
Ao contrário do pacote jwt-decode npm, que apenas decodifica tokens, esta ferramenta também codifica e decodifica tokens com qualquer algoritmo HMAC ou RSA, verifica assinaturas e gera chaves secretas, tudo sem sair do navegador. As principais bibliotecas JWT em outras linguagens incluem PyJWT (Python), jjwt (Java), golang-jwt (Go) e jose (Rust), use esta ferramenta para testar tokens gerados por qualquer uma delas.
Como usar esta ferramenta
Decodificar um JWT
- Cole o JWT codificado que você deseja inspecionar no campo Decodificar JWT.
- Clique em Decodificar JWT.
- O cabeçalho e a carga útil aparecem como JSON formatado – você pode ver todas as declarações que o emissor escolheu codificar no token. Verifique as declarações, o algoritmo, o carimbo de data e hora de expiração, o emissor e quaisquer campos personalizados, não é necessária nenhuma chave de assinatura.
Codifique um JWT
- Selecione um algoritmo de assinatura no menu suspenso, HS256 para codificar com HMAC, RS256 ou PS256 para codificar com RSA.
- Insira sua chave secreta (HMAC) ou chave privada no formato PEM (RSA/RSA-PSS).
- Edite o JSON do cabeçalho para definir alg e typ.
- Edite o JSON da carga útil com suas declarações, sub, iat, exp, funções ou quaisquer campos personalizados.
- Clique em Codificar JWT para codificar e assinar seu token em uma única etapa.
Verifique uma assinatura JWT
- Cole o token no campo Verificar JWT.
- Insira a chave secreta (HMAC) ou a chave pública no formato PEM (RSA/RSA-PSS). O algoritmo é lido automaticamente do cabeçalho do token.
- Clique em Verificar JWT. A ferramenta executa novamente o mesmo processo usado para codificar a assinatura e compara o resultado. Válido = correspondências de assinatura. Inválido = chave errada ou carga útil adulterada.
Gere uma chave secreta
- Selecione o comprimento da chave – 256 bits para HS256, 384 bits para HS384, 512 bits para HS512.
- Clique em Gerar segredo.
- Copie e armazene a chave em uma variável de ambiente ou gerenciador de segredos. Nunca coloque segredos de assinatura no código-fonte. Para formatos secretos adicionais, consulte nosso Gerador de Senhas.
Como ler seus resultados
Cabeçalho decodificado
O cabeçalho decodificado revela as configurações escolhidas quando o JWT foi codificado. É um objeto JSON com dois campos padrão: alg (o algoritmo de assinatura, "HS256", "RS256", "PS256", etc.) e typ (sempre "JWT"). Se um campo kid (Key ID) estiver presente, ele identifica qual chave foi usada para assinar o token – usado quando um servidor de autorização publica várias chaves públicas por meio de um endpoint JWKS (JSON Web Key Set) e as alterna ao longo do tempo.
Carga útil decodificada
A carga contém as declarações do token – dados sobre o assunto autenticado. As reivindicações registradas padrão incluem sub (assunto, normalmente um ID de usuário), iss (emissor), aud (público), exp (expiração, um carimbo de data/hora Unix), iat (emitido em), nbf (não antes) e jti (ID JWT). As declarações personalizadas adicionadas pelo seu aplicativo (funções, IDs da organização, escopos de permissão, nível de assinatura) também aparecem aqui.
A carga útil é codificada em Base64URL, não criptografada. Qualquer pessoa com o token pode decodificar e ler a carga. Nunca armazene senhas, detalhes de pagamento, identidades nacionais ou dados pessoais confidenciais em uma carga JWT. Para tokens que devem transportar dados confidenciais, use JWE (RFC 7516).
Resultado da verificação de assinatura
A verificação recalcula a assinatura que foi criada quando o token foi codificado, usando o cabeçalho, a carga útil e a chave fornecida e, em seguida, compara-a byte a byte com a assinatura codificada no token. Valid confirma que o token foi assinado pelo titular dessa chave e nada foi alterado. Inválido significa que a chave está errada ou o token foi adulterado após a assinatura. A decodificação por si só nunca prova a autenticidade – sempre verifique antes de agir com base em qualquer afirmação na produção.
Estrutura do token JWT
Um JWT consiste em três strings codificadas em Base64URL unidas por pontos: [cabeçalho].[carga útil].[assinatura]. Quando você codifica um JWT, cada seção é codificada em Base64URL e unida por pontos. Ao decodificá-lo, cada seção é separada e exibida como JSON. O cabeçalho identifica o algoritmo. A carga útil carrega as reivindicações. A assinatura prova que nenhum dos dois foi alterado.
[header].[payload].[signature]Aqui está um exemplo de token JWT mostrando como as três partes são divididas:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 ← cabeçalho
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ ← payload
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ← assinaturaCole este exemplo de JWT no decodificador acima para ver cada parte decodificada.
Cabeçalho
O cabeçalho é um objeto JSON que você codifica no JWT como Base64URL. Especifica o tipo de token ("JWT") e o algoritmo usado para criar a assinatura, por exemplo "HS256" (HMAC-SHA256) ou "RS256" (RSASSA-PKCS1-v1_5). Alguns tokens incluem um garoto (ID da chave) para informar ao destinatário qual chave pública usar para verificação quando o emissor faz a rotação das chaves.
Carga útil
A carga útil é um objeto JSON que contém as declarações, codificadas em Base64URL, mas não criptografadas. A RFC 7519 define três categorias de declarações: declarações registradas (nomes padronizados como sub, iss, exp), declarações públicas (registradas no registro de declarações JSON Web Token da IANA para evitar colisões) e declarações privadas (campos personalizados específicos do aplicativo acordados entre o emissor e o consumidor).
Assinatura
A assinatura é a assinatura digital que torna os JWTs resistentes a adulteração: ela une o cabeçalho e o payload e prova que ambos vieram de uma fonte confiável. Para algoritmos HMAC, é HMACSHA256(base64url(header) + "." + base64url(payload), secret). Para RSA, uma chave privada assina e qualquer detentor da chave pública correspondente verifica. Altere um único byte no cabeçalho ou no payload depois da assinatura e a assinatura se torna inválida, que é a garantia de segurança central do JWS (RFC 7515).
Reivindicações JWT comuns
As declarações registradas JWT são nomes de campos padronizados definidos na RFC 7519. Os mais importantes são exp (tempo de expiração), sub (assunto, geralmente um ID de usuário), iss (emissor) e aud (público). Todos são opcionais, mas amplamente implementados nos sistemas OAuth 2.0 e OIDC.
Nomes de declarações registradas RFC 7519, opcionais, mas amplamente suportados em sistemas OAuth 2.0 e OIDC:
Reivindicar | Nome Completo | Tipo | Valor de exemplo | Descrição |
|---|---|---|---|---|
| iss | Emissor | String/URI | "https://auth.example.com" | O servidor ou aplicativo que emitiu o token |
| sub | Assunto | Corda | "user_abc123" | Sobre quem se trata o token – geralmente um ID de usuário |
| aud | Público | String/matriz | "api.example.com" | Quais serviços devem aceitar este token |
| exp | Tempo de expiração | Data Numérica | 1716239022 | Carimbo de data/hora Unix, o token é inválido após este ponto |
| nbf | Não antes | Data Numérica | 1716235422 | O token não deve ser aceito antes deste carimbo de data/hora |
| iat | Emitido em | Data Numérica | 1716235422 | Quando o token foi criado |
| jti | ID do JWT | Corda | "a1b2c3d4e5" | Identificador único; usado para prevenir ataques de repetição |
| kid | ID da chave | Corda | "2025-key-01" | Identifica qual chave assinou o token quando várias chaves estão em uso |
Os valores NumericDate (exp, nbf, iat) são segundos desde a época Unix - 00:00:00 UTC de 1º de janeiro de 1970.
Ao codificar um JWT, adicione declarações privadas para dados específicos do aplicativo: funções, nível de assinatura, ID da organização, escopos de permissão. Use um nome no estilo URI, como "https://yourapp.com/role" para evitar futuras colisões de registro da IANA.
Algoritmos de assinatura suportados
Esta ferramenta suporta todas as três variantes HMAC (HS256, HS384, HS512) e todas as seis variantes RSA/RSA-PSS (RS256, RS384, RS512, PS256, PS384, PS512), conforme definido no RFC 7518 (JSON Web Algorithms). Escolha HMAC para configurações de serviço único; escolha RSA para sistemas distribuídos onde os serviços verificam tokens sem compartilhar a chave de assinatura.
Algoritmo | Família | Tipo de chave | Preenchimento | Uso recomendado |
|---|---|---|---|---|
| HS256 | HMAC | Segredo compartilhado | — | Padrão para autenticação de serviço único |
| HS384 | HMAC | Segredo compartilhado | — | Hash mais forte para requisitos de conformidade |
| HS512 | HMAC | Segredo compartilhado | — | Força máxima do HMAC |
| RS256 | RSA | Par de chaves | PKCS#1 v1.5 | Amplamente suportado; uso em sistemas distribuídos |
| RS384 | RSA | Par de chaves | PKCS#1 v1.5 | Hash mais longo para a família RS |
| RS512 | RSA | Par de chaves | PKCS#1 v1.5 | Força máxima de RS |
| PS256 | RSA-PSS | Par de chaves | PSS (probabilistic) | Preferido ao RS256 para novas implementações |
| PS384 | RSA-PSS | Par de chaves | PSS (probabilistic) | - |
| PS512 | RSA-PSS | Par de chaves | PSS (probabilistic) | - |
HMAC (simétrico), HS256, HS384, HS512
Os algoritmos HMAC (definidos na RFC 2104) usam um segredo compartilhado para assinatura e verificação. Tanto o emissor do token quanto todo serviço que verifica os tokens devem conter o mesmo segredo.
- HS256: HMAC com SHA-256. O algoritmo de assinatura JWT mais comum em todo o ecossistema. Comprimento mínimo recomendado do segredo: 256 bits (32 bytes).
- HS384: HMAC com SHA-384. Use quando sua política de segurança exigir um tamanho de hash maior.
- HS512: HMAC com SHA-512. Resistência máxima do HMAC para ambientes de alta conformidade.
RSA e RSA-PSS (assimétrico), RS256, RS384, RS512, PS256, PS384, PS512
Os algoritmos RSA usam um par de chaves. Os sinais da chave privada; a chave pública verifica. Os serviços de verificação precisam apenas da chave pública, que pode ser publicada abertamente por meio de um endpoint JWKS.
- RS256 / RS384 / RS512: Preenchimento RSASSA-PKCS1-v1_5. Amplamente suportado em todas as bibliotecas e plataformas JWT.
- PS256 / PS384 / PS512: Preenchimento RSASSA-PSS. Esquema de assinatura probabilística com propriedades de segurança mais fortes do que PKCS#1 v1.5. Recomendado sobre variantes RS para novas implementações (ver RFC 8017).
Tamanho mínimo da chave RSA: 2.048 bits; prefira 4096 bits para chaves de assinatura de longa duração. Use HMAC quando um serviço emite e verifica tokens. Use RSA ou RSA-PSS quando serviços independentes precisarem verificar tokens sem compartilhar o segredo de assinatura.
Vulnerabilidades de segurança JWT
JWT é seguro quando implementado corretamente. Três vulnerabilidades aparecem consistentemente em auditorias de segurança de API: o desvio alg:none, confusão de algoritmo e segredos HMAC fracos. Todos decorrem de erros de implementação, não de falhas na RFC 7519. A RFC 8725 (JWT Best Current Practices, IETF) fornece orientação confiável de mitigação.
O ataque alg:none
Um invasor modifica o cabeçalho do token para definir “alg”: “none” e, em seguida, remove o segmento de assinatura. Se o servidor aceitar o campo alg do cabeçalho do token sem validação, ele ignorará totalmente a verificação da assinatura e confiará no token não assinado.
Sempre coloque os algoritmos aceitos na lista de permissões do lado do servidor. Nunca deixe o cabeçalho do token determinar qual algoritmo usar ao codificar ou verificar; derive isso da sua própria configuração. Todas as principais bibliotecas JWT têm um parâmetro algorithms explícito: passe-o. Exemplo: jwt.verify(token, secret, {'{'} algorithms: ['HS256'] {'}'})
Confusão de algoritmo (RS256 a HS256)
Se um servidor usar uma chave pública RSA para verificar tokens, mas não aplicar alg, um invasor poderá alterar o cabeçalho para "alg": "HS256" e assinar o token usando a chave pública como segredo HMAC. O servidor então trata a chave pública como um segredo HMAC compartilhado e aceita o token forjado.
Aplique o algoritmo esperado no lado do servidor. Nunca use o mesmo material chave para múltiplas famílias de algoritmos. Configure explicitamente sua biblioteca para aceitar apenas RS256 ou PS256 ao usar chaves RSA.
Segredos fracos do HMAC
Os tokens HS256 assinados com segredos curtos ou adivinhados podem sofrer força bruta off-line. Um invasor que intercepta um token válido pode executar ataques de dicionário ou de tabela arco-íris contra a assinatura sem qualquer interação com o servidor. Segredos fracos comuns incluem "segredo", "senha" ou nomes de aplicativos.
Use o gerador de segredo integrado nesta página para produzir uma chave criptograficamente aleatória de 256 bits (ou mais). Gire o segredo imediatamente em qualquer suspeita de exposição.
Validação de declaração ausente
Uma assinatura válida prova que o token foi emitido por uma parte conhecida – não prova que o token é apropriado para a solicitação atual. A falha na validação de exp (expiração), aud (público) ou iss (emissor) permite que os invasores reproduzam tokens expirados, usem tokens emitidos para um serviço diferente ou usem tokens de um emissor não confiável.
Sempre valide exp para rejeitar tokens expirados. Valide aud para garantir que o token foi emitido para seu serviço específico. Valide iss para rejeitar tokens de emissores inesperados. A maioria das bibliotecas JWT lidam com essas verificações automaticamente se você passar os valores esperados nas opções de verificação.
JWT versus autenticação baseada em sessão
JWTs não têm estado – todos os dados da sessão são codificados no token. A autenticação baseada em sessão armazena dados da sessão no servidor e fornece ao cliente apenas um ID de sessão. Os JWTs são melhor dimensionados horizontalmente; sessões suportam revogação instantânea.
Recurso | JWT (sem estado) | Baseado em sessão (com estado) |
|---|---|---|
| Onde o estado é armazenado | Dentro do token (lado do cliente) | Lado do servidor (banco de dados ou cache) |
| Escalabilidade | Horizontal – sem armazenamento de sessão compartilhada | Requer armazenamento de sessão compartilhada em configurações de vários servidores |
| Revogação | Não é possível revogar antes do vencimento sem uma lista de bloqueios | Imediato, exclua o registro da sessão |
| Tamanho do token | Maior (~200–500 bytes típico) | ID de sessão pequena (~20–40 bytes) |
| Uso entre domínios/API | Fácil – cabeçalho Bearer padrão | Requer configuração de compartilhamento de cookies |
| Microsserviços | Ideal – cada serviço é verificado localmente | Cada serviço deve consultar o armazenamento de sessão |
| Dados confidenciais em token | Não criptografado por padrão (use JWE) | Nunca exposto ao cliente |
| Melhor para | APIs, microsserviços, aplicativos móveis, SSO | Aplicativos web tradicionais renderizados em servidor |
Escolha JWT para APIs distribuídas, microsserviços, aplicativos móveis, logon único (SSO) e qualquer arquitetura em que vários serviços independentes precisem verificar tokens sem compartilhar um armazenamento de sessão.
Escolha sessões para aplicativos que exigem revogação imediata de token (sistemas financeiros, ferramentas administrativas), aplicativos web tradicionais renderizados em servidor ou sistemas onde o tamanho do token é uma restrição.
Privacidade e segurança
- Funciona inteiramente no seu navegador.Toda codificação, decodificação, verificação e geração de chaves acontecem no lado do cliente por meio da Web Crypto API e JavaScript. Quer você codifique um novo token ou decodifique um existente, nenhum dado será enviado a nenhum servidor. Como todas as ferramentas em nosso Kit de ferramentas de segurança , esta ferramenta é totalmente do lado do cliente.
- Nada é armazenado ou registrado.Nenhum registro é mantido de qualquer token, segredo ou carga inserida.
- Codificado não é criptografado.As cargas úteis JWT (JWS) são codificadas em Base64URL – legíveis por qualquer pessoa com o token. A assinatura digital torna a carga útil à prova de falsificação, mas não privada. Para tokens que devem transportar dados confidenciais, use JWE (JSON Web Encryption, RFC 7516). Esta ferramenta lida apenas com JWS.
- A decodificação não é autenticação.Ler o conteúdo de um token não prova que ele é válido ou confiável. Sempre verifique a assinatura – e valide exp, aud e iss – antes de agir em qualquer reclamação na produção.
- Trate as chaves de assinatura como senhas.Use o gerador aqui para obter uma chave criptograficamente aleatória com o comprimento correto. Armazene-o em uma variável de ambiente ou em um gerenciador de segredos dedicado. Gire-o se suspeitar de exposição. Nunca o comprometa com o controle de versão.
Perguntas frequentes
Perguntas Frequentes