Pular para o conteúdo principal

Questão de Arquitetura de Software — Segurança da Informação — FCC 2023

Arquitetura de SoftwareSegurança da Informação
Código
fc069498
Banca
FCC
Órgão
TRT - 12ª Região (SC)
Ano
2023
Nível
Superior
Cargo
Analista Judiciário - Área de Apoio Especializado (Especialidade Tecnologia da Informação)
O Auth2 foi construído com base em quatro papéis (ou atores) principais, cada um com responsabilidades específicas no processo de autorização. Esses papéis são:
  1. AResource Owner, Client, Resource Server e Authorization Server.
  2. BAuthorization Agent, Client, Authentication Server e End User.
  3. CIdentity Provider, Client, Authorization Agent e Authentication Server.
  4. DProtected Resource Server, Resource Agent, Identity Provider e Authentication Serve.
  5. EEnd User, Client, Resource Provider e Authentication Server.
Revelar gabarito e comentário

GabaritoA — Resource Owner, Client, Resource Server e Authorization Server.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

OAuth 2.0: Papéis (Atores) no Fluxo de Autorização

Gabarito: letra A. OAuth 2.0 define quatro papéis principais, conforme especificação RFC 6749: Resource Owner, Client, Resource Server e Authorization Server. É exatamente essa composição que a alternativa correta apresenta. As demais alternativas incluem termos que não fazem parte da especificação ou trocam nomes, como “Authorization Agent”, “Identity Provider”, “Authentication Server”, “End User” (que é sinônimo de Resource Owner, mas não é o termo oficial do papel), entre outros.

A banca cobra o conhecimento dos atores canônicos do OAuth 2.0, que são:

  • Resource Owner (Proprietário do Recurso): a entidade que pode conceder acesso a um recurso protegido (geralmente o usuário final).

  • Client (Cliente): a aplicação que faz as requisições de acesso protegido em nome do Resource Owner.

  • Resource Server (Servidor de Recursos): o servidor que hospeda os recursos protegidos e aceita e responde a requisições com tokens de acesso.

  • Authorization Server (Servidor de Autorização): o servidor que emite tokens de acesso ao Client após autenticar o Resource Owner e obter sua autorização.

Papel (OAuth 2.0)

Descrição (Responsabilidade)

Nome Oficial (RFC 6749)

Resource Owner

Entidade que concede acesso a um recurso protegido (geralmente o usuário final).

Resource Owner

Client

Aplicação que solicita acesso protegido em nome do Resource Owner.

Client

Resource Server

Servidor que hospeda os recursos protegidos e aceita/responde requisições com tokens de acesso.

Resource Server

Authorization Server

Servidor que emite tokens de acesso ao Client após autenticar o Resource Owner e obter autorização.

Authorization Server

1Resource Owner
Concede acesso ao recurso
Geralmente o usuário final
2Client
Aplicação que requisita acesso
Em nome do Resource Owner
3Resource Server
Hospeda recursos protegidos
Aceita tokens de acesso
4Authorization Server
Emite tokens de acesso
Autentica e obtém autorização
OAuth 2.0 (RFC 6749)
LEVELsoulevel.com.br
OAuth 2.0 (RFC 6749): Resource Owner (Concede acesso ao recurso, Geralmente o usuário final); Client (Aplicação que requisita acesso, Em nome do Resource Owner); Resource Server (Hospeda recursos protegidos, Aceita tokens de acesso); Authorization Server (Emite tokens de acesso, Autentica e obtém autorização)

Alternativa A — ✅ Correta ⟵ GABARITO

Lista exatamente os quatro papéis definidos pelo OAuth 2.0: Resource Owner, Client, Resource Server e Authorization Server. Não há erro.

Alternativa B — ❌ Incorreta

Substitui “Resource Owner” por “End User” (que é um conceito próximo, mas o termo oficial é Resource Owner) e troca “Resource Server” por “Authentication Server” (que não é um papel do OAuth 2.0 – o servidor de autenticação é parte do Authorization Server, mas não é um papel separado). Além disso, inclui “Authorization Agent”, que não existe no modelo.

Alternativa C — ❌ Incorreta

Inclui “Identity Provider” e “Authentication Server”, que não são papéis do OAuth 2.0. O Authorization Server pode atuar como Identity Provider, mas não é um papel distinto. “Authorization Agent” também não é um papel padrão.

Alternativa D — ❌ Incorreta

Mistura termos: “Protected Resource Server” (é o Resource Server, mas o nome correto é Resource Server), “Resource Agent” (inexistente), “Identity Provider” e “Authentication Server”. Não corresponde aos quatro papéis.

Alternativa E — ❌ Incorreta

Novamente usa “End User” (não é papel oficial), “Resource Provider” (não é papel) e “Authentication Server”. Apenas “Client” está correto, mas o conjunto está errado.

PEGA ESSA DICA!

Memorize os quatro papéis exatos do OAuth 2.0: Resource Owner, Client, Resource Server e Authorization Server. Em provas, desconfie de alternativas que incluam “Authentication Server”, “Identity Provider”, “Authorization Agent” ou “End User” como papéis principais – todos estão fora da especificação canônica.

Link permanente: /questoes/fc069498