Questão de Segurança da Informação — OAuth — FCC 2026

OAuth 2.1: estratégia de tokens para APIs de mobilidade

Gabarito: letra B. A alternativa correta combina as recomendações centrais do OAuth 2.1 e das melhores práticas de segurança de APIs: access tokens de vida curta, refresh tokens com rotação e revogação automática em caso de reutilização, escopos específicos por tipo de cliente e, para clientes de alto risco, vinculação do token ao cliente via mTLS ou DPoP. Essa combinação minimiza o impacto do roubo de dispositivos e do comprometimento de quiosques, pois limita a janela de uso de um token roubado e permite detectar e revogar o abuso.

O OAuth 2.1 é uma consolidação das melhores práticas do OAuth 2.0, incorporando recomendações de segurança que antes estavam em documentos separados (como o BCP 6749 e o RFC 9700). Seu foco é reduzir a superfície de ataque de tokens, especialmente em cenários com clientes públicos (aplicativos móveis) e dispositivos que podem ser fisicamente comprometidos, como quiosques de autoatendimento. O protocolo define quatro atores principais: o Resource Owner (usuário dono dos dados), o Client (aplicação que quer acessar os recursos), o Authorization Server (emite os tokens) e o Resource Server (protege os recursos e valida os tokens).

A lógica por trás da estratégia correta é o princípio do menor privilégio combinado com a redução do tempo de exposição. Um access token de vida curta (minutos, não horas) significa que, mesmo se for roubado, o atacante tem uma janela pequena para usá-lo. O refresh token, por sua vez, é a chave para obter novos access tokens sem exigir novo login, mas precisa ser protegido com rotação: a cada uso, um novo refresh token é emitido e o antigo é invalidado. Se um atacante tentar reutilizar um refresh token já usado, o sistema detecta a reutilização e revoga a sessão inteira — é a chamada "detecção de reutilização". Isso é crucial em cenários de roubo de celular: se o dispositivo for roubado e o atacante tentar usar o refresh token, a rotação faz com que o token legítimo do usuário seja invalidado, e a revogação automática corta o acesso.

Os escopos específicos por tipo de cliente são outra camada essencial. Um aplicativo de terceiros que só precisa consultar rotas não deve receber um token com permissão para recarregar créditos ou emitir recibos. Isso limita o dano caso um cliente específico seja comprometido. Para clientes de alto risco — como quiosques públicos, que podem ser fisicamente violados —, a vinculação do token ao cliente (sender-constrained token) via mTLS (mutual TLS) ou DPoP (Demonstration of Proof-of-Possession) impede que um token roubado seja usado em outro dispositivo, pois o Resource Server exige prova de posse de uma chave privada que só existe no dispositivo original.

A distinção que importa aqui é entre tokens "bearer" e tokens "sender-constrained". Um bearer token é como uma senha: quem o possui, usa. Se for roubado, o atacante pode usá-lo de qualquer lugar. Já um sender-constrained token (mTLS ou DPoP) exige que o cliente prove que é o dono legítimo do token, apresentando uma chave privada vinculada àquele token. Isso torna o roubo do token inútil sem a chave privada correspondente. A tabela abaixo resume a diferença:

A pegadinha que a banca explora neste tema é a tentação de simplificar a segurança em nome da experiência do usuário. Alternativas que propõem tokens de longa duração, refresh tokens reutilizáveis ou armazenamento inseguro parecem "práticas" do ponto de vista operacional, mas violam frontalmente as recomendações de segurança do OAuth 2.1. A banca também explora a confusão entre access token e refresh token, e entre autenticação e autorização. Guarde a fronteira entre "token de curta duração + rotação + revogação" e "token de longa duração + reutilização": é exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Trata os tokens JWT como chaves de API, com validade de 24 horas, e dispensa mecanismos de revogação ou detecção de uso indevido. Isso é um erro grave: um token de 24 horas roubado dá ao atacante um dia inteiro de acesso. Além disso, o OAuth 2.1 recomenda explicitamente que access tokens tenham vida curta e que mecanismos de revogação sejam implementados. A alternativa também confunde o papel de chaves de API (autenticação de cliente) com o de access tokens (autorização em nome do usuário).

Alternativa B — ✅ Correta ⟵ GABARITO

Esta é a única alternativa que segue integralmente as recomendações do OAuth 2.1: access tokens de vida curta, refresh tokens com rotação e revogação automática em caso de reutilização, escopos específicos por tipo de cliente e, para clientes de alto risco, vinculação do token ao cliente via mTLS ou DPoP. Cada elemento ataca um vetor de ataque específico: a vida curta limita a janela de uso de um token roubado; a rotação e a revogação detectam e cortam o abuso de refresh tokens; os escopos limitam o dano por cliente; e o mTLS/DPoP impede o uso do token em outro dispositivo.

Alternativa C — ❌ Incorreta

Propõe tokens de acesso com validade de um ano e sem refresh tokens. Isso é o oposto do recomendado: tokens de longa duração aumentam drasticamente o impacto de um roubo, e a ausência de refresh tokens não elimina a necessidade de renovação — apenas força o usuário a refazer o login com frequência, prejudicando a experiência. A justificativa de "reduzir a carga sobre o Authorization Server" não se sustenta frente ao risco de segurança.

Alternativa D — ❌ Incorreta

Fornece refresh tokens de longa duração, reutilizáveis e compartilhados entre múltiplos dispositivos. Isso viola o princípio da rotação e da revogação: um refresh token reutilizável, se roubado, dá acesso contínuo ao atacante. Compartilhar o mesmo refresh token entre dispositivos também é problemático, pois um dispositivo comprometido compromete todos os outros. A vinculação por mTLS/DPoP não compensa a falta de rotação e a reutilização.

Alternativa E — ❌ Incorreta

Armazenar refresh tokens em texto claro em banco de dados local é uma violação grave de segurança. Mesmo com segmentação de rede e controles físicos, um quiosque comprometido expõe os tokens diretamente. A alternativa ignora a recomendação de armazenar tokens de forma segura (criptografados, em hardware seguro) e de usar sender-constrained tokens para dispositivos de alto risco.

Gabarito: letra B