Segurança da Informação · FCC · 2026 | Questão sqc-fc077557

Segurança da InformaçãoAutenticação

Código: fc077557
Banca: FCC
Órgão: SEFAZ-SP
Ano: 2026
Nível: Superior

Cargo: Auditor Fiscal da Receita Estadual - AFRE - Tecnologia da Informação e Comunicação - Conhecimentos Especificos (P3)

Uma instituição expôs uma AP| RESTful protegida por JWT com várias instâncias atrás de um balanceador, em que o login gera access token de 2 horas, que é validado em cada requisição por meio da assinatura da data de expiração e das claims de roles. Porém, após um incidente de credenciais vazadas, a equipe detectou que, mesmo após o usuário trocar a senha, os tokens antigos continuam válidos até expirarem inclusive em diferentes serviços que compartilham a mesma chave de assinatura. Para que a equipe possa mitigar esse problema mantendo a escalabilidade e o modelo stateless da API, a estratégia mais adequada é

Aadicionar no payload do JWT um campo “revogado false” e atualizar esse campo para true no banco, deixando que as APIs leiam o token e confiem no valor recebido.
Bgravar todos os JWT emitidos em uma tabela relacional e validar cada requisição consultando essa tabela, garantindo revogação imediata ao excluir o registro do token.
Cusar access tokens de curta duração combinados com refresh tokens e uma claim de versão de credencial, invalidando tokens quando a versão do usuário muda ao validar o JWT nas APIs.
Daumentar o tempo de expiração do JWT e rotacionar a chave de assinatura com mais frequência, levando os clientes a refazer login quando a chave for alterada.
Eincluir no JWT a senha hash do usuário e rejeitar tokens cujo hash não coincida com o valor atual no banco, garantindo que a troca de senha invalide automaticamente os tokens antigos.

Revelar gabarito e comentário

GabaritoC — usar access tokens de curta duração combinados com refresh tokens e uma claim de versão de credencial, invalidando tokens quando a versão do usuário muda ao validar o JWT nas APIs.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Autenticação com JWT e Revogação de Tokens

Gabarito: letra C. A estratégia mais adequada para revogar tokens JWT mantendo a escalabilidade e o modelo stateless é usar access tokens de curta duração combinados com refresh tokens e uma claim de versão de credencial. Quando o usuário troca a senha, a versão é incrementada; a API valida que a versão no token corresponde à versão atual do usuário no banco. Isso permite revogação sem armazenar tokens ativos, preservando a natureza stateless dos access tokens.

A questão aborda o problema comum de revogação de JWT. JWT é assinado e auto-contido; uma vez emitido, não pode ser revogado sem um mecanismo adicional, pois validar cada token contra um banco quebraria o stateless. A solução clássica é encurtar a vida do access token e usar refresh tokens (que podem ser armazenados e revogados) juntamente com um número de versão da credencial. Quando a senha muda, a versão é atualizada e os tokens antigos (com versão anterior) são rejeitados.

Estratégia	Descrição	Mantém stateless?	Permite revogação imediata?
C (Gabarito)	Access token curto + refresh token + claim de versão de credencial	Sim (access token)	Sim (via versão)
A	Campo "revogado" no payload + consulta em banco	Não	Sim
B	Gravar todos os JWTs em tabela + consulta por requisição	Não	Sim
D	Aumentar expiração + rotacionar chave de assinatura	Sim	Não (após troca de chave)
E	Incluir hash da senha no JWT + validar contra banco	Não	Sim

Alternativa A — ❌ Incorreta

Adicionar campo "revogado false" no payload e verificar em banco quebra a natureza stateless da API, pois cada requisição precisaria de uma consulta ao banco para validar o token. Além disso, a claim no JWT pode ser manipulada se o token não for validado contra o banco (já que o próprio token afirma que não está revogado).

Alternativa B — ❌ Incorreta

Gravar todos os JWTs emitidos em tabela relacional e consultá-los quebra o stateless, pois toda requisição exigiria acesso ao banco. Isso elimina as vantagens de escalabilidade horizontal do JWT.

Alternativa C — ✅ Correta ⟵ GABARITO

Utiliza access tokens de curta duração (ex.: minutos) + refresh tokens + uma claim de versão de credencial. Quando o usuário altera a senha, a versão armazenada no servidor (banco de refresh tokens) é incrementada. O access token contém essa versão. Ao receber o token, a API verifica se a versão no token coincide com a versão atual do usuário (essa consulta pode ser otimizada em cache). Assim, tokens antigos são rejeitados imediatamente. Os refresh tokens são armazenados e podem ser revogados. A solução mantém o stateless para access tokens e é escalável.

Alternativa D — ❌ Incorreta

Aumentar a expiração do JWT e rotacionar a chave de assinatura com frequência não resolve o problema: tokens antigos continuam válidos até expirar, e rotacionar a chave força todos os clientes a reautenticarem, o que é ineficiente e quebra a experiência do usuário. Além disso, o problema de revogação imediata não é atendido.

Alternativa E — ❌ Incorreta

Incluir o hash da senha no JWT expõe material sensível e quebra o stateless, pois para verificar o hash a API precisaria consultar o banco a cada requisição. Além disso, se o hash for comprometido, a senha original pode ser atacada. Não é uma prática segura.

PEGA ESSA DICA!

Lembre-se: JWT é auto-contido por design. Qualquer solução que precise de consulta a um banco para validar cada requisição quebra o stateless. A solução de versionamento com refresh tokens é a mais adotada na prática para revogação sem estado.

Gabarito: letra C.

Link permanente: /questoes/fc077557