Questão de Segurança da Informação — OAuth — VUNESP 2025

OAuth 2.0: Access Tokens e o Servidor de Recursos

Gabarito: letra B. No OAuth 2.0, o access token é a credencial que o cliente apresenta ao servidor de recursos (resource server) para acessar recursos protegidos em nome do usuário — é exatamente o papel que a alternativa B descreve. As demais alternativas confundem o papel dos tokens: o cliente não deve interpretar o access token, sender-constrained tokens exigem prova de posse de chave privada, bearer tokens não carregam identificação do usuário de forma codificada, e ID tokens (do OpenID Connect) servem para identificação, não para acesso a recursos.

O OAuth 2.0 é um protocolo de autorização, não de autenticação. Ele permite que uma aplicação (cliente) acesse recursos protegidos em nome de um usuário (resource owner) sem expor as credenciais deste. O fluxo envolve quatro atores principais: o resource owner (dono do recurso), o cliente (aplicação que quer acessar), o authorization server (que autentica o usuário e emite tokens) e o resource server (que hospeda e protege os recursos, validando os access tokens). O access token é a peça central: ele representa a autorização concedida, tem vida curta e pode conter escopos (permissões específicas).

A regra de ouro é: quem valida e interpreta o access token é o resource server, nunca o cliente. O cliente apenas repassa o token nas requisições. Isso é uma decisão de segurança: se o cliente pudesse interpretar o token, ele poderia extrair informações sensíveis ou ser enganado por tokens forjados. O resource server, por sua vez, conhece o formato e a assinatura dos tokens que emite (diretamente ou via authorization server) e é o único que deve confiar neles.

Na prática, imagine um aplicativo de terceiros (cliente) que quer acessar as fotos do usuário no Google (resource server). O usuário autoriza o acesso, o Google (authorization server) emite um access token para o aplicativo. O aplicativo então envia esse token em cada requisição à API de fotos. O Google valida o token e, se válido, retorna as fotos. O aplicativo nunca "abre" o token para ver o que tem dentro — ele só o usa como uma chave de acesso.

A distinção crucial que a banca explora é entre access token e ID token. O access token é do OAuth 2.0 e serve para acessar recursos. O ID token é uma extensão do OpenID Connect (camada de autenticação sobre o OAuth 2.0) e serve para informar quem é o usuário autenticado — ele é entregue ao cliente, que pode interpretá-lo. Confundir esses dois papéis é a armadilha central desta questão.

Guarde a fronteira: access token → recurso (resource server) · ID token → identidade (cliente interpreta). É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que o cliente deve interpretar os access tokens. Isso é o oposto da regra: o cliente não deve interpretar o conteúdo do access token, apenas repassá-lo. Quem valida e entende o token é sempre o resource server. O cliente não precisa (e não deve) saber o que está dentro do token — ele só o usa como credencial de acesso.

Alternativa B — ✅ Correta ⟵ GABARITO

Esta é a definição correta do access token: ele é usado pelo cliente para efetuar requisições ao resource server, que valida o token e retorna os recursos protegidos. O access token representa a autorização concedida pelo usuário e é a credencial de acesso aos recursos.

Alternativa C — ❌ Incorreta

Afirma que sender-constrained tokens não requerem prova de posse de chave privada. É o contrário: sender-constrained tokens são um tipo mais seguro de access token que exige que o cliente comprove a posse de uma chave privada (conceito de proof of possession — PoP). Isso impede que o token seja reutilizado por terceiros em caso de vazamento.

Alternativa D — ❌ Incorreta

Afirma que bearer tokens incluem, de forma codificada, informações de identificação do usuário. Bearer tokens são tokens que "quem possui, usa" — eles não carregam, por si só, informações de identificação do usuário de forma codificada. Quem carrega informações de identificação do usuário é o ID token (do OpenID Connect), não o bearer token. O bearer token é apenas uma credencial de acesso.

Alternativa E — ❌ Incorreta

Afirma que ID tokens devem ser usados para acessar o resource server. Isso confunde ID token com access token. O ID token é uma extensão do OpenID Connect e serve para identificar o usuário autenticado — ele é entregue ao cliente, que pode interpretá-lo. Para acessar recursos no resource server, o token correto é o access token, não o ID token.

Gabarito: letra B