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

OAuth 2.0: Tokens de Acesso e Refresh Tokens

Gabarito: letra C. No OAuth 2.0 (RFC 6749), a emissão de um refresh token é opcional e fica a critério do servidor de autorização (authorization server). As demais alternativas confundem os papéis dos tokens: access tokens e authorization grants não são intercambiáveis, refresh tokens não são usados para obter novos authorization grants, e o refresh token nunca é apresentado ao servidor de recursos (resource server) — ele é trocado apenas junto ao servidor de autorização.

O OAuth 2.0 é um protocolo de autorização (e não de autenticação) que permite que uma aplicação (cliente) acesse recursos protegidos em nome de um usuário (proprietário do recurso), sem que o usuário precise compartilhar suas credenciais com a aplicação. O fluxo envolve quatro atores principais: o proprietário do recurso (resource owner), o cliente (client), o servidor de autorização (authorization server) e o servidor de recursos (resource server). O servidor de autorização é quem emite os tokens de acesso após autenticar o usuário e obter seu consentimento; o servidor de recursos é quem hospeda os dados protegidos e valida o access token antes de liberar o acesso.

O access token é o token principal do protocolo: é ele que o cliente apresenta ao servidor de recursos para obter o recurso protegido. Ele representa a autorização concedida, tem vida curta e pode carregar escopos (permissões específicas). Já o refresh token é um token de validade mais longa, usado para obter um novo access token quando o atual expira, sem exigir que o usuário faça login novamente. Por isso, o refresh token é enviado somente ao servidor de autorização — nunca ao servidor de recursos. A emissão do refresh token não é obrigatória: a RFC 6749 prevê que o servidor de autorização pode emiti-lo ou não, conforme sua política. Essa é a distinção central que a questão explora.

Na prática, imagine um aplicativo de celular que acessa a API de um banco. O usuário faz login uma vez; o servidor de autorização emite um access token (válido por, digamos, 30 minutos) e, opcionalmente, um refresh token (válido por dias). Quando o access token expira, o aplicativo usa o refresh token para pedir um novo access token ao servidor de autorização — sem incomodar o usuário. O refresh token nunca vai para a API do banco (servidor de recursos); quem recebe o access token é a API. Se o servidor de autorização decidir não emitir refresh token, o aplicativo simplesmente terá de refazer o login quando o access token expirar.

A pegadinha da banca está em trocar os papéis dos tokens: as alternativas A, B, D e E misturam authorization grants, access tokens, refresh tokens e os servidores envolvidos. Guarde a fronteira: access token → servidor de recursos; refresh token → servidor de autorização; authorization grant → é a credencial usada para obter o access token (ex.: authorization code). É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que access tokens e authorization grants podem ser usados de modo intercambiável. Isso é falso: são coisas distintas. O authorization grant é a credencial que representa a autorização do proprietário do recurso e é usada pelo cliente para obter um access token (por exemplo, o authorization code no fluxo Authorization Code). O access token é o resultado dessa troca — a credencial efetivamente usada para acessar o recurso protegido. Não há intercambialidade: um é o meio, o outro é o fim.

Alternativa B — ❌ Incorreta

Afirma que refresh tokens e access tokens podem ser usados de modo intercambiável. Também é falso. O access token é apresentado ao servidor de recursos para obter o recurso; o refresh token é apresentado ao servidor de autorização para obter um novo access token. São funções distintas e não intercambiáveis — o refresh token nunca substitui o access token no acesso ao recurso.

Alternativa C — ✅ Correta ⟵ GABARITO

A emissão de um refresh token é opcional e fica a critério do servidor de autorização. A RFC 6749 não obriga o servidor a emitir refresh tokens; ele pode decidir emiti-los ou não, conforme sua política e o tipo de concessão. É exatamente o que a alternativa afirma, e por isso está correta.

Alternativa D — ❌ Incorreta

Afirma que refresh tokens são usados para obter novos authorization grants. Errado: o refresh token é usado para obter um novo access token, não um novo authorization grant. O authorization grant é a credencial inicial (ex.: authorization code) que dá origem ao primeiro access token; o refresh token serve para renovar o access token sem refazer todo o fluxo de autorização.

Alternativa E — ❌ Incorreta

Afirma que o cliente deve apresentar um refresh token ao servidor de recursos para obter um recurso protegido. Errado: quem é apresentado ao servidor de recursos é o access token. O refresh token é enviado somente ao servidor de autorização, nunca ao servidor de recursos. Apresentar o refresh token ao servidor de recursos seria um erro grave de segurança e de protocolo.

Gabarito: letra C