Decodificador JWT Gratuito

Uma breve história dos JSON Web Tokens

O JSON Web Token (JWT) foi padronizado como RFC 7519 em maio de 2015 por Michael B. Jones (Microsoft), John Bradley (Ping Identity) e Nat Sakimura (NRI) sob o Grupo de Trabalho JOSE da IETF. Foi a culminação de meia década de trabalho: o primeiro internet-draft de JWT apareceu em dezembro de 2010, surgindo do formato pesado de asserção baseado em XML do SAML 2.0 (2005) e da necessidade sentida de algo mais leve que os navegadores pudessem analisar nativamente. O avanço foi escolher JSON em vez de XML e base64url em vez de PEM: um JWT podia caber em uma string de consulta de URL ou em um cabeçalho Authorization: Bearer. Toda a família JOSE foi entregue como um conjunto coordenado: RFC 7515 (JWS) para assinatura, RFC 7516 (JWE) para criptografia, RFC 7517 (JWK) para o formato de chave, RFC 7518 (JWA) para identificadores de algoritmo e RFC 7519 (JWT) para a camada de afirmações, todos no mesmo dia de maio de 2015. A adoção foi instantânea. OAuth 2.0 (RFC 6749, 2012) tinha padronizado tokens de acesso mas deixou seu formato opaco; a indústria escolheu JWT. OpenID Connect (dezembro de 2014, OpenID Foundation) tornou JWT obrigatório para tokens ID. Em 2017, todo grande provedor de identidade (Auth0, Okta, Azure AD, AWS Cognito, Google Identity, Firebase Auth) emitia JWTs como seu formato nativo de sessão. JWT.io, o site decodificador que a Auth0 lançou em 2014, tornou-se a ferramenta de depuração JWT de fato e ajudou a cimentar o domínio mental do formato entre desenvolvedores. Dois incidentes de segurança moldaram o modelo de ameaça moderno: a divulgação de Tim McLean em 2015 do bypass alg: none e do ataque de confusão de algoritmo HS/RS, e CVE-2022-21449 (abril de 2022), o bug «Psychic Signatures» de Neil Madden no verificador ECDSA de Java 15-18. Ambos levaram ao endurecimento padrão das bibliotecas: a maioria das bibliotecas modernas agora recusa alg: none de imediato e fixa o algoritmo esperado em vez de lê-lo do cabeçalho do token.

A anatomia de um JWT

• Três segmentos codificados em base64url. Um JWT é a string header.payload.signature: três segmentos separados por pontos, cada um codificado em base64url. A RFC 7519 chama isso de JWT Compact Serialization. Tudo cabe em uma URL ou cabeçalho HTTP; essa compactação foi o objetivo de design que distinguiu JWT de predecessores baseados em XML como SAML.
• Cabeçalho. Um pequeno objeto JSON contendo normalmente dois campos: alg (o algoritmo de assinatura, por ex. HS256, RS256, ES256) e typ (quase sempre «JWT»). Campos opcionais incluem kid (um identificador de chave usado para rotação de chaves) e cty (tipo de conteúdo para tokens aninhados). O cabeçalho diz ao verificador como validar a assinatura; nunca confie nele sozinho, sempre fixe o algoritmo esperado no lado do servidor.
• Payload. Um objeto JSON de afirmações, asserções chave-valor sobre um sujeito. A RFC 7519 §4.1 reserva sete afirmações padrão: iss (emissor), sub (sujeito), aud (audiência), exp (expiração), nbf (não antes), iat (emitido em) e jti (ID JWT único). Os emissores adicionam afirmações personalizadas livremente. O payload é assinado mas não criptografado: qualquer um com o token pode lê-lo.
• Assinatura. A prova criptográfica de que o cabeçalho e o payload não foram adulterados. A entrada de assinatura é a string literal base64url(header) + "." + base64url(payload); a assinatura em si é então codificada em base64url como o terceiro segmento. A verificação requer o segredo simétrico (HS*) ou a chave pública assimétrica (RS*, ES*, PS*, EdDSA) e deve sempre acontecer em um servidor confiável.
• base64url, não base64. Os segmentos JWT usam a variante base64 segura para URL definida na RFC 4648 §5: o caractere 62 é - em vez de +, o caractere 63 é _ em vez de /, e o preenchimento final = é removido. O atob() integrado do JavaScript só lida com base64 padrão, então decodificadores JWT traduzem o alfabeto e re-preenchem antes de decodificar.
• NumericDate: segundos, não milissegundos. A RFC 7519 define exp, nbf e iat como «o número de segundos desde 1970-01-01T00:00:00Z UTC». O Date.now() do JavaScript retorna milissegundos, então um bug comum é um exp três ordens de magnitude grande demais, produzindo um token que «expira» por volta do ano 53.000. Sempre use Math.floor(Date.now() / 1000) ao emitir tokens.

Onde os JWTs são usados na prática

• Tokens de acesso OAuth 2.0. A RFC 6749 deixou o formato do token de acesso opaco, mas na prática a indústria padronizou em JWT. Auth0, Okta, Azure AD, AWS Cognito e Google Identity emitem todos tokens de acesso JWT por padrão. O token Bearer no seu cabeçalho Authorization é quase sempre um JWT.
• Tokens ID do OpenID Connect. OIDC (dezembro de 2014) exige JWT para seu id_token. O id_token carrega afirmações de identidade sobre o usuário autenticado (sub, email, name, picture) e é consumido pela parte confiante em vez de passado adiante. Este é o mecanismo principal por trás de «Entrar com Google», «Entrar com Apple» e fluxos equivalentes.
• Autenticação de API. APIs REST sem estado adotam JWT porque remove a necessidade de um armazenamento de sessão no lado do servidor: a API confia no que a assinatura verifica. Chaves de API estilo Stripe continuam comuns para tráfego servidor-a-servidor, mas para APIs com escopo de usuário, o padrão Authorization: Bearer <jwt> é agora o predefinido.
• Autenticação microsserviço-a-microsserviço. Um JWT com escopo de usuário emitido na borda da API é encaminhado através de chamadas internas serviço-a-serviço, permitindo que cada serviço confie na autenticação original sem re-autenticar. O padrão às vezes é chamado de «tradução de token»: o gateway de borda troca uma sessão opaca por um JWT de curta duração com escopo para a chamada descendente.
• Sessões de aplicativos de página única. SPAs (React, Vue, Angular) historicamente armazenaram tokens de acesso em localStorage por conveniência. A orientação moderna (OWASP, Auth0) é manter tokens de acesso em memória e tokens de refresh em cookies HttpOnly + Secure + SameSite=Strict, porque localStorage é legível por qualquer XSS que pouse na página.
• Sessões de aplicativos móveis. Apps iOS e Android armazenam tokens de acesso no Keychain ou Keystore da plataforma. O token é enviado como Authorization: Bearer em cada chamada ao backend. Tokens de refresh são rotacionados em cada uso, e o curto exp do token de acesso (tipicamente 5-15 minutos) é a defesa principal contra repetição de dispositivo roubado.

Padrões e marcos de segurança

• RFC 7519 (JWT, maio de 2015). A especificação base. Define a JWT Compact Serialization, as sete afirmações padrão registradas (iss, sub, aud, exp, nbf, iat, jti) e o formato NumericDate. Autores: Michael B. Jones, John Bradley, Nat Sakimura.
• RFC 7515 (JWS, maio de 2015). JSON Web Signature. O formato de invólucro assinado que quase todo mundo informalmente chama de «JWT»: três segmentos base64url unidos por pontos. JWS suporta tanto a forma compacta quanto a JSON Serialization; JWT só usa a forma compacta.
• RFC 7516 (JWE, maio de 2015). JSON Web Encryption. A variante criptografada com cinco segmentos (cabeçalho, chave criptografada, IV, texto cifrado, tag de autenticação). Use JWE, não JWS, quando o payload deve ser confidencial, não apenas evidente quanto a adulteração.
• RFC 7517 (JWK, maio de 2015). JSON Web Key. A representação JSON de chaves criptográficas. O endpoint JWKS (/.well-known/jwks.json) publica um JSON Web Key Set, o mecanismo moderno para rotação de chaves sem tempo de inatividade: verificadores procuram chaves por kid.
• RFC 7518 (JWA, maio de 2015). JSON Web Algorithms. O registro de identificadores alg: HS256/384/512 (HMAC), RS256/384/512 (RSASSA-PKCS1-v1_5), ES256/384/512 (ECDSA), PS256/384/512 (RSASSA-PSS), EdDSA (Ed25519/Ed448) e o none (intencionalmente raramente usado).
• O bypass alg: none (Tim McLean, 2015). A RFC 7518 lista none como um valor de algoritmo válido para contextos não seguros. Verificadores ingênuos aceitavam um token com o cabeçalho reescrito para {"alg":"none"} e uma assinatura vazia, permitindo que um atacante forjasse qualquer payload. Bibliotecas modernas recusam none por padrão; a própria especificação afirma que verificadores «NÃO DEVEM aceitar JWSs não seguros por padrão».
• Ataque de confusão de algoritmo HS/RS (Tim McLean, 2015). Se um verificador escolhe o algoritmo do cabeçalho do token em vez de fixá-lo, um atacante pode reescrever o cabeçalho para HS256 e assinar o token usando a chave pública RSA do servidor como segredo HMAC. A biblioteca vê HS256, trata a chave pública RSA configurada como um segredo simétrico, e a assinatura é validada. Mitigação: fixe o algoritmo esperado fora de banda; nunca o derive do token.
• CVE-2022-21449 «Psychic Signatures» (Neil Madden, abril de 2022). O verificador ECDSA de Java 15-18 não verificava que os valores r e s da assinatura eram diferentes de zero, o que significa que uma assinatura literal toda-zero era aceita como válida. JWTs assinados com ES256/384/512 nas JVMs afetadas podiam ser forjados com uma assinatura em branco. Corrigido na Atualização Crítica de Patch da Oracle de abril de 2022.

Perguntas frequentes adicionais

Ferramentas relacionadas