Questão de Segurança da Informação — Questões Mescladas de Autenticação e Controle de Acesso — CESPE / CEBRASPE 2026
Segurança da Informação›Questões Mescladas de Autenticação e Controle de Acesso
Código
ce390763
Banca
CESPE / CEBRASPE
Órgão
TCE RN
Ano
2026
Cargo
Ana Adm ( )
A respeito dos princípios de segurança da informação, julgue o item a seguir. O protocolo OAuth 2.0 é utilizado para a autenticação de usuários, enquanto o OpenID Connect é utilizado para a autorização de acesso a recursos.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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 e OpenID Connect: autorização × autenticação
❌ ERRADO. A afirmação inverte os papéis dos dois protocolos: o OAuth 2.0 é um protocolo de autorização (conceder acesso a recursos), enquanto o OpenID Connect (OIDC) é uma camada de autenticação construída sobre o OAuth 2.0 (identificar quem é o usuário). O gabarito é a letra E.
O OAuth 2.0 (RFC 6749) foi projetado para resolver um problema específico: permitir que uma aplicação (cliente) acesse recursos protegidos em nome de um usuário (resource owner) sem que o usuário precise compartilhar suas credenciais com essa aplicação. Para isso, o protocolo define quatro papéis — resource owner, client, authorization server e resource server — e um mecanismo de emissão de tokens de acesso (access tokens). O ponto central é que o OAuth 2.0 não define nenhum mecanismo para verificar a identidade do usuário; ele apenas delega a autorização de acesso. Por isso, dizer que o OAuth 2.0 é usado para autenticação é um erro conceitual grave.
O OpenID Connect (OIDC), por sua vez, é uma extensão do OAuth 2.0 que adiciona exatamente essa camada de autenticação. Ele introduz o ID Token (um JWT assinado) que contém informações sobre o usuário autenticado (nome, e-mail, identificador único), permitindo que o cliente saiba quem é o usuário. Em outras palavras: o OIDC usa o fluxo de autorização do OAuth 2.0 para, no final, entregar também uma prova de identidade. A relação é de complementaridade: o OIDC depende do OAuth 2.0, mas o OAuth 2.0 não depende do OIDC.
A confusão entre autenticação e autorização é uma das mais exploradas em provas de segurança da informação. Autenticação responde à pergunta "quem é você?" (verificação de identidade); autorização responde à pergunta "o que você pode fazer?" (permissão de acesso a recursos). A autenticação sempre precede a autorização: primeiro se identifica o usuário, depois se verifica se ele tem permissão para executar determinada operação. No contexto dos protocolos, essa distinção é crucial: o OAuth 2.0 cuida da segunda parte (autorização), enquanto o OIDC cuida da primeira (autenticação).
Para fixar, veja a comparação com outros padrões comuns:
Protocolo
Função principal
Base
Uso típico
OAuth 2.0
Autorização
JSON (tokens)
APIs e apps móveis
OpenID Connect
Autenticação (sobre OAuth 2.0)
JSON (ID Token)
SSO em apps web/móveis
SAML
Autenticação e autorização
XML
SSO corporativo
JWT
Formato de token (autenticação e autorização)
JSON
Transmissão de claims
A pegadinha da questão está exatamente na inversão dos papéis: o candidato que decora "OAuth = login com Google" sem entender a arquitetura acaba marcando "Certo". Mas o login com Google via OAuth 2.0, na prática, usa o OpenID Connect por cima — o OAuth 2.0 sozinho não autentica ninguém.
NÃO CAIA NESSA!
A banca inverte os papéis dos dois protocolos. O candidato que associa OAuth 2.0 a "fazer login" (porque vê o botão "Entrar com Google") cai na armadilha. Mas o OAuth 2.0 é autorização; a autenticação nesse fluxo vem do OpenID Connect, que é a camada construída sobre ele. Guarde: OAuth 2.0 = "o que você pode acessar"; OIDC = "quem você é".
Item — ❌ Errado
A afirmação diz que "OAuth 2.0 é utilizado para a autenticação de usuários, enquanto o OpenID Connect é utilizado para a autorização de acesso a recursos". Isso está invertido. O OAuth 2.0 é um protocolo de autorização — ele concede acesso a recursos protegidos por meio de tokens, sem se preocupar com a identidade do usuário. O OpenID Connect é uma camada de autenticação construída sobre o OAuth 2.0, que adiciona o ID Token para identificar o usuário. Portanto, a assertiva está errada.