Cyberpediapor Brain
PTDEENESFRITNL

JSON Web Token (JWT)

Um JWT é o comprovativo que uma aplicação lhe entrega depois de iniciar sessão. O que a assinatura verifica, as armadilhas e os gestos a adotar.

Em 30 segundos

Onde acontece
Com a plataforma de identidade da Microsoft, que autentica os utilizadores e fornece tokens de acesso, de atualização e de identidade1.
O que quer o atacante
Roubar um token válido para agir com os direitos do seu titular, sem conhecer a palavra-passe2.
O reflexo
Nunca enviar nem publicar um token ou um endereço que contenha um, terminar a sessão após a utilização e comunicar qualquer comportamento anormal.
Se já aconteceu
Terminar a sessão e avisar o serviço informático. A OWASP lembra que apagar um cookie não basta: «deleting a cookie alone does not invalidate a stolen copy of the session ID», sendo necessária a invalidação no servidor6.

Do que se trata

Depois de iniciar sessão numa aplicação da empresa, esta entrega-lhe um comprovativo digital que o navegador ou a aplicação apresenta em cada pedido. Na Microsoft, esse comprovativo assume a forma de um JSON Web Token, ou JWT, que contém «claims», ou seja, declarações sobre o utilizador ou a aplicação1.

Um JWT pode ser descodificado, por exemplo no site jwt.ms, e a sua assinatura serve para verificar a autenticidade do token3. Esta ficha apresenta os gestos do colaborador e os do responsável.

Perguntas diretas

O que é um JWT?

Um JWT tem três segmentos separados por um ponto: o cabeçalho, o corpo e a assinatura3. O corpo contém as claims. A assinatura serve para avaliar a autenticidade do token3.

A assinatura impede que o token seja lido?

A assinatura serve para verificar a autenticidade do token. A Microsoft indica que os programadores podem descodificar um JWT com um site como o jwt.ms, para validação e depuração3. O token é sensível e representa um risco de segurança se for mal manuseado3.

Um token roubado permite mesmo agir em meu nome?

Sim. A MITRE descreve adversários que usam tokens de acesso roubados para contornar o processo habitual de autenticação e aceder a contas, informações ou serviços. Esses tokens são usados em vez das credenciais de início de sessão2.

Um token roubado continua válido durante muito tempo?

Depende da sua duração de vida. Nos tokens de acesso da Microsoft, a duração por defeito é um valor aleatório entre 60 e 90 minutos, 75 minutos em média3. Os inquilinos sem acesso condicional têm uma duração por defeito de duas horas para clientes como o Microsoft Teams e o Microsoft 3653. A MITRE observa, no entanto, que o adversário pode por vezes roubar também um token de atualização, que lhe permite obter novos tokens de acesso sem solicitar o utilizador4.

1Como funciona1 min

O servidor de autorização assina o token com uma chave privada e publica a chave pública correspondente. Para validar um token, a aplicação verifica a assinatura com essa chave pública1. O cabeçalho do JWT indica o algoritmo de assinatura (claim alg) e a chave pública a utilizar (claim kid)3. O Microsoft Entra ID emite tokens assinados com algoritmos assimétricos padrão, como o RS2563.

O token de acesso é transmitido a uma API como token «bearer» no cabeçalho Authorization1. Como os tokens são válidos por um período limitado, o servidor fornece muitas vezes um par: um token de acesso e um token de atualização, que serve para renovar o primeiro quando se aproxima do fim da validade1. O token de atualização só dá um novo token de acesso se o utilizador continuar autorizado1.

No caso do OpenID Connect, o ID Token é um JWT assinado que permite a uma aplicação verificar a identidade do utilizador5.

2O que faz2 min

Como colaborador:

  • Nunca envie um token, nem um endereço web que contenha um, numa mensagem, num pedido de assistência ou num fórum. Os identificadores de sessão colocados num endereço podem ir parar a ligações, registos, ao histórico do navegador, aos favoritos, ao cabeçalho Referer ou a motores de pesquisa6.
  • Termine a sessão quando acabar. Uma aplicação deve oferecer um botão de terminar sessão visível e acessível, para que o utilizador possa encerrar a sua sessão a qualquer momento6.
  • Não conte com o fecho do navegador: não permite impor de forma fiável o fim da sessão, nomeadamente em dispositivos móveis6.
  • Comunique qualquer comportamento anormal (sessões terminadas sem motivo, ações que não realizou, pedido para autorizar uma aplicação desconhecida). A MITRE descreve atacantes que conseguem que seja concedido acesso a uma aplicação maliciosa através do envio de uma ligação de phishing dirigido4.

Como responsável, a exigir às equipas e aos fornecedores:

  • A validação da assinatura e do emissor pela aplicação que recebe o token, com os valores publicados no documento de descoberta do OpenID3.
  • O controlo da audiência: uma API só deve aceitar os tokens cuja claim aud lhe corresponda. Aceitar um token destinado a outro recurso é um exemplo do problema do «confused deputy»3.
  • Bibliotecas testadas em vez de código feito internamente. A Microsoft recomenda as suas bibliotecas MSAL, que tratam da obtenção, da atualização e da validação dos tokens1.
  • Durações de sessão limitadas. A OWASP cita como intervalos habituais de tempo de inatividade 2 a 5 minutos para aplicações de grande valor e 15 a 30 minutos para as de baixo risco, e pede também um limite absoluto, independentemente da atividade6.
  • Um armazenamento prudente no navegador (ver a secção seguinte).
3As armadilhas2 min

A MITRE indica que os tokens roubados são «used in lieu of login credentials», isto é, usados em vez das credenciais de início de sessão2. A MITRE observa que os cookies de sessão podem contornar certos protocolos de autenticação multifator7.

Vários erros de implementação repetem-se nas fontes.

  • O armazenamento no navegador. A OWASP desaconselha guardar tokens de autenticação, identificadores de sessão, JWT ou tokens de atualização em localStorage ou sessionStorage: estes espaços são acessíveis a qualquer JavaScript executado na origem, pelo que uma única falha XSS divulga todos os tokens6. A OWASP prefere cookies HttpOnly, Secure e SameSite=Strict, ou um modelo do tipo Backend-for-Frontend6.
  • O token no endereço. Um identificador transmitido pelo URL pode vazar e facilitar outros ataques, como a fixação de sessão6.
  • Uma validação feita no sítio errado. Segundo a Microsoft, um cliente não deve tentar validar um token de acesso: cabe à API fazê-lo, e o cliente trata-o como uma cadeia opaca3.
  • A confiança no conteúdo sem verificar a assinatura. Uma aplicação que tem de validar um token começa por verificar a assinatura e o emissor3.
  • Tokens roubados na infraestrutura. Em ambientes Kubernetes ou em cadeias de integração e de implementação contínuas, os tokens de API podem ser roubados se o contentor ou a cadeia forem comprometidos4.
  • O roubo de sessão por um script malicioso ou por um proxy de phishing. A MITRE cita software malicioso que visa os cookies do navegador e ferramentas livres como o Evilginx2 e o Muraena, que recolhem cookies através de um proxy malicioso7.

As fontes citadas aqui não detalham outros erros de conceção frequentemente citados, como o algoritmo «none», a confusão entre chaves ou os segredos fracos. Este ponto deve ser verificado pelas equipas de desenvolvimento com os seus próprios referenciais.

Ficha

Identificador
CP-195
Ala
3. Protocolos e defesa
Competência Brain
Controlar os acessos (control_access)
Reflexo Brain
cr-027
Esquema
G3 · Corte anatómico
Idiomas
de, en, es, fr, it, nl, pt
Fontes
7 fontes verificadas em 3 de novembro de 2026
Fontes7 fontes
  1. Microsoft, «Tokens and claims overview - Microsoft identity platform», 21 de março de 2025. https://learn.microsoft.com/en-us/entra/identity-platform/security-tokens (consultado em 3 de novembro de 2026)
  2. MITRE ATT&CK, «Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1550/001/ (consultado em 3 de novembro de 2026)
  3. Microsoft, «Access tokens in the Microsoft identity platform - Microsoft identity platform», 14 de maio de 2025. https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens (consultado em 3 de novembro de 2026)
  4. MITRE ATT&CK, «Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1528/ (consultado em 3 de novembro de 2026)
  5. OWASP, «Authentication - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html (consultado em 3 de novembro de 2026)
  6. OWASP, «Session Management - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (consultado em 3 de novembro de 2026)
  7. MITRE ATT&CK, «Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1539/ (consultado em 3 de novembro de 2026)

Citar este artigo

Brain, «JSON Web Token (JWT)», Cyberpedia, 2026. https://startbrain.io/cyberpedia/pt/articles/jwt-json-web-token-assinatura-armadilhas/

BibTeX 
@misc{brain_cp195_pt_2026,
  author = {Brain},
  title = {JSON Web Token (JWT)},
  year = {2026},
  howpublished = {Cyberpedia},
  url = {https://startbrain.io/cyberpedia/pt/articles/jwt-json-web-token-assinatura-armadilhas/},
  note = {CC BY 4.0}
}
Licença CC BY 4.0