GabaritoC — proprietário do recurso.
Gabarito: letra C. No protocolo OAuth, a entidade capaz de conceder acesso a um recurso protegido é o proprietário do recurso (resource owner), pois é ele quem detém os dados e autoriza o cliente a acessá-los — o servidor de autorização apenas emite o token após essa autorização. Essa definição consta na especificação do OAuth (RFC 6749) e é o papel central do fluxo de delegação de acesso.
O OAuth (Open Authorization) é um padrão aberto de delegação de autorização que permite que um aplicativo (cliente) acesse recursos protegidos em nome de um usuário, sem compartilhar as credenciais desse usuário. Em vez de entregar a senha, o usuário autoriza o acesso e o sistema emite um token que o cliente usa para acessar os recursos. Para entender a questão, é essencial conhecer os quatro atores definidos pela especificação:
Resource Owner (proprietário do recurso): a entidade que possui os recursos protegidos e pode conceder acesso a eles. No caso mais comum, é o usuário final.
Resource Server (servidor de recurso): o servidor que hospeda os recursos protegidos e exige um token válido para liberar o acesso. É a API que contém os dados.
Client (cliente): a aplicação que solicita acesso aos recursos protegidos em nome do proprietário.
Authorization Server (servidor de autorização): o servidor que autentica o proprietário e emite os tokens de acesso após a autorização.
A pegadinha clássica da banca é confundir quem autoriza (proprietário do recurso) com quem emite o token (servidor de autorização). O proprietário concede o acesso; o servidor de autorização apenas materializa essa concessão emitindo o token. Veja o fluxo típico do Authorization Code Flow:
O cliente solicita acesso ao proprietário do recurso.
O proprietário autoriza o acesso (geralmente fazendo login e consentindo).
O cliente envia a autorização ao servidor de autorização.
O servidor de autorização emite um código de autorização e, depois, o token de acesso.
O cliente usa o token para acessar o servidor de recurso.
A distinção entre os papéis é o critério decisivo desta questão: a alternativa correta é a que identifica o proprietário do recurso como a entidade capaz de conceder acesso. As demais alternativas descrevem outros atores com funções diferentes.
O cliente é a aplicação que requisita o acesso aos recursos protegidos, não a entidade que concede o acesso. Ele depende da autorização do proprietário e do token emitido pelo servidor de autorização para conseguir acessar os dados. A banca pode tentar confundir o cliente com o proprietário, mas o cliente é apenas o solicitante.
O servidor de autorização é responsável por autenticar o proprietário e emitir os tokens de acesso, mas não é ele quem concede o acesso ao recurso. Ele apenas valida a autorização dada pelo proprietário e gera o token. A concessão em si é uma decisão do proprietário do recurso. Essa é a confusão mais comum: trocar o papel de quem autoriza pelo de quem emite o token.
O proprietário do recurso (resource owner) é a entidade que detém os recursos protegidos e pode conceder acesso a eles. No OAuth, ele é quem autoriza o cliente a acessar seus dados, geralmente por meio de uma tela de consentimento. A definição literal da especificação diz: "Resource Owner: uma entidade capaz de conceder acesso a um recurso protegido (pode ser o usuário final)". É exatamente o que o enunciado pede.
O servidor de recurso é o servidor que hospeda os recursos protegidos e verifica os tokens antes de liberar o acesso. Ele não concede o acesso por decisão própria; apenas valida se o token apresentado é válido e se as permissões (escopos) são suficientes. A concessão lógica vem do proprietário, materializada no token.
A banca adora inverter os papéis entre proprietário do recurso e servidor de autorização. Lembre-se: o proprietário autoriza (decide conceder), o servidor de autorização emite (materializa a autorização em token). Se a alternativa disser que o servidor de autorização "concede acesso", está errada — ele apenas emite o token após a autorização do proprietário. Com treino, você enxerga essa troca de longe 💪.
Para fixar os quatro atores do OAuth, monte uma tabela mental com a função de cada um:
Ator | Função |
|---|---|
Resource Owner | Possui e concede acesso |
Client | Solicita acesso |
Authorization Server | Autentica e emite tokens |
Resource Server | Hospeda e valida tokens |
Na prova, quando a questão perguntar "quem concede acesso", a resposta é sempre o proprietário do recurso.
Gabarito: letra C
Link permanente: /questoes/ce404044