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

OAuth 2.0: Papéis e Emissão de Tokens

Gabarito: letra D. No OAuth 2.0, o servidor de autorização é o componente responsável por emitir tokens de acesso, e esses tokens podem ser aceitos por múltiplos servidores de recursos. Essa é a arquitetura central do protocolo: um único provedor de identidade (servidor de autorização) pode emitir tokens válidos para diversas APIs (servidores de recursos), como ilustra o exemplo de um login único do governo que emite tokens para sistemas de IPVA, Nota Fiscal Paulista e ITCMD.

O OAuth 2.0 (RFC 6749) define quatro papéis principais: o proprietário do recurso (resource owner), que é o usuário ou sistema que possui os dados e pode conceder acesso a eles; o cliente (client), que é a aplicação que deseja acessar os recursos protegidos; o servidor de autorização (authorization server), que autentica o proprietário e emite os tokens de acesso; e o servidor de recursos (resource server), que hospeda os dados protegidos e valida os tokens antes de conceder o acesso. A distinção fundamental entre os dois servidores é que o servidor de autorização emite os tokens, enquanto o servidor de recursos valida e consome esses tokens para liberar o acesso aos dados.

A relação entre esses servidores é o ponto central desta questão. O servidor de autorização é uma entidade centralizada que pode emitir tokens para vários servidores de recursos. Isso é o que permite, por exemplo, que um usuário faça login uma única vez (via Google, Facebook ou um provedor corporativo) e utilize esse mesmo token para acessar diferentes APIs. O servidor de recursos, por sua vez, é o destinatário final do token: ele o recebe, valida sua assinatura e verifica se o escopo é suficiente para liberar o recurso solicitado. Um servidor de recursos não emite tokens; ele apenas os consome.

A pegadinha desta questão está em inverter os papéis: as alternativas incorretas atribuem ao servidor de recursos a capacidade de emitir tokens, o que é uma confusão clássica. O servidor de recursos é quem valida o token, não quem o emite. A emissão é função exclusiva do servidor de autorização. Além disso, a relação de cardinalidade é importante: um servidor de autorização pode atender a múltiplos servidores de recursos, e não apenas a um único. Essa é a arquitetura que viabiliza o SSO (Single Sign-On) e a federação de identidades.

Guarde a fronteira: quem emite é o servidor de autorização; quem valida é o servidor de recursos. E a cardinalidade: um servidor de autorização → muitos servidores de recursos. É exatamente nesses dois critérios que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que um servidor de recursos pode emitir tokens de acesso. Isso está errado: o servidor de recursos não emite tokens; ele apenas valida os tokens recebidos e libera o acesso aos recursos protegidos. A emissão de tokens é função exclusiva do servidor de autorização. A alternativa confunde o papel de quem emite com o de quem consome.

Alternativa B — ❌ Incorreta

Afirma que um servidor de recursos pode emitir tokens aceitos por, no máximo, um único servidor de autorização. Há dois erros aqui: primeiro, o servidor de recursos não emite tokens; segundo, a relação correta é inversa — o servidor de autorização emite tokens que podem ser aceitos por múltiplos servidores de recursos. A alternativa inverte completamente os papéis e a cardinalidade.

Alternativa C — ❌ Incorreta

Afirma que um servidor de recursos pode emitir tokens aceitos por múltiplos servidores de autorização. Novamente, o erro está em atribuir ao servidor de recursos a capacidade de emitir tokens. Quem emite é o servidor de autorização. Além disso, a relação correta é que um servidor de autorização emite tokens para múltiplos servidores de recursos, e não o contrário.

Alternativa D — ✅ Correta ⟵ GABARITO

Esta é a alternativa correta. O servidor de autorização é o componente que emite os tokens de acesso, e esses tokens podem ser aceitos por múltiplos servidores de recursos. Essa é a arquitetura padrão do OAuth 2.0: um provedor de identidade centralizado (como Google, Facebook ou um servidor corporativo) emite tokens que são válidos para diversas APIs. O exemplo clássico é o login único do governo: um único servidor de autorização emite tokens para os sistemas de IPVA, Nota Fiscal Paulista e ITCMD.

Alternativa E — ❌ Incorreta

Afirma que um servidor de autorização pode emitir tokens aceitos por, no máximo, um único servidor de recursos. O erro está na cardinalidade: o servidor de autorização pode emitir tokens para múltiplos servidores de recursos, não apenas para um. Essa é a base do SSO e da federação de identidades, onde um único login dá acesso a diversos sistemas.

Gabarito: letra D