Questão de Segurança da Informação — OpenID Connect — FCC 2026
Segurança da Informação›OpenID Connect
Código
fc141888
Banca
FCC
Órgão
SEFAZ SP
Ano
2026
Cargo
AFRE ( )
A equipe de desenvolvimento de uma Secretaria da Fazenda está analisando protocolos para implementar o SSO no Portal do Contribuinte. Considerando os requisitos de segurança, a delegação segura de autorização e a necessidade de obter informações básicas do perfil do cidadão (como nome e CPF) para personalização do portal, a equipe de desenvolvimento optou por
Aimplementar autenticação básica HTTP com criptografia SSL/TLS, armazenando as credenciais em sessão no servidor da Secretaria.
Butilizar OAuth 2.0 com o fluxo Client Credentials, em que a aplicação da Secretaria se autentica diretamente no servidor gov.br para acessar recursos em nome do próprio sistema.
Cadotar OpenID Connect sobre OAuth 2.0, utilizando o fluxo de Authorization Code com PKCE (Proof Key for Code Exchange), em que o gov.br atua como provedor de identidade.
Dconfigurar OpenID Connect para troca de assertions XML entre a Secretaria e o gov.br, com autenticação baseada em certificados digitais.
Eimplementar API Keys estáticas, em que cada contribuinte recebe uma chave única para autenticar diretamente nas APIs da Secretaria, sem intermediários.
Revelar gabarito e comentário▾
GabaritoC — adotar OpenID Connect sobre OAuth 2.0, utilizando o fluxo de Authorization Code com PKCE (Proof Key for Code Exchange), em que o gov.br atua como provedor de identidade.
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”.
OpenID Connect e SSO: autenticação federada com OAuth 2.0
Gabarito: letra C. A equipe deve adotar OpenID Connect sobre OAuth 2.0, usando o fluxo Authorization Code com PKCE, com o gov.br atuando como provedor de identidade (IdP). Isso atende aos três requisitos: SSO (autenticação única), delegação segura de autorização (OAuth 2.0) e obtenção de informações do perfil do cidadão (ID Token do OIDC).
O cenário descreve um caso clássico de Single Sign-On (SSO) federado: o Portal do Contribuinte precisa autenticar cidadãos que já possuem identidade no gov.br, sem armazenar senhas localmente. O OpenID Connect (OIDC) é uma camada de autenticação construída sobre o OAuth 2.0, que é um protocolo de autorização. Enquanto o OAuth 2.0 emite access tokens para acessar recursos, o OIDC adiciona o ID Token (um JWT) que contém informações sobre o usuário autenticado — exatamente o que a questão pede ao mencionar "nome e CPF".
O fluxo Authorization Code com PKCE é o mais recomendado para aplicações web e mobile, pois o código de autorização é trocado por tokens no servidor, e o PKCE (Proof Key for Code Exchange) adiciona uma camada de proteção contra interceptação do código. O gov.br, como provedor de identidade, autentica o cidadão e emite os tokens para o Portal. Isso elimina a necessidade de a Secretaria armazenar credenciais dos contribuintes, reduzindo o risco de vazamento e centralizando a autenticação em uma entidade confiável.
A alternativa correta é a única que combina autenticação (OIDC), autorização (OAuth 2.0) e perfil do usuário (ID Token), tudo com o fluxo mais seguro disponível. As demais alternativas apresentam falhas conceituais ou de segurança que as tornam inadequadas para o cenário.
NÃO CAIA NESSA!
A banca tenta confundir OAuth 2.0 (autorização) com OpenID Connect (autenticação). A alternativa B usa OAuth 2.0 com Client Credentials, que é para comunicação máquina a máquina, não para autenticar usuários. A alternativa D mistura OIDC com SAML (XML), que são protocolos distintos. A alternativa E usa API Keys, que não servem para autenticação de usuários. A alternativa A é a mais perigosa: parece segura por usar SSL/TLS, mas armazenar credenciais em sessão no servidor é uma prática vulnerável e não resolve o SSO.
OpenID Connect (OIDC)
1Camada de autenticação sobre OAuth 2.0
2Emite ID Token (JWT) com perfil do usuário
3Fluxo recomendado: Authorization Code + PKCE
4Provedor de identidade (IdP) centraliza autenticação
5OAuth 2.0
Protocolo de autorização
Emite access tokens para recursos
Fluxo Client Credentials: máquina a máquina
6Protocolos distintos
SAML: assertions XML
OIDC: tokens JWT em JSON
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Autenticação básica HTTP com SSL/TLS armazena credenciais em sessão no servidor. Isso não implementa SSO, pois cada sistema precisaria de sua própria sessão. Além disso, armazenar credenciais em sessão é uma prática insegura, sujeita a ataques como sequestro de sessão. O SSL/TLS apenas protege o tráfego, não resolve a autenticação federada.
Alternativa B — ❌ Incorreta
O fluxo Client Credentials do OAuth 2.0 é para comunicação máquina a máquina, onde a aplicação se autentica com suas próprias credenciais, sem envolvimento do usuário. Não serve para autenticar cidadãos no Portal. Além disso, o OAuth 2.0 sozinho não fornece informações de perfil do usuário (como nome e CPF) — isso é função do ID Token do OIDC.
Alternativa C — ✅ Correta ⟵ GABARITO
OpenID Connect sobre OAuth 2.0 com Authorization Code + PKCE é a solução ideal. O gov.br atua como provedor de identidade (IdP), autenticando o cidadão e emitindo o ID Token (com nome, CPF, etc.) e o access token (para acessar recursos). O PKCE protege o fluxo contra interceptação do código de autorização, sendo recomendado para aplicações web e mobile. Isso atende a todos os requisitos: SSO, delegação segura de autorização e obtenção do perfil do usuário.
Alternativa D — ❌ Incorreta
OpenID Connect não usa assertions XML — isso é característica do SAML (Security Assertion Markup Language). O OIDC usa tokens JWT em JSON. A alternativa mistura dois protocolos distintos. Embora certificados digitais possam ser usados, a descrição está conceitualmente errada.
Alternativa E — ❌ Incorreta
API Keys estáticas são para autenticar clientes de API, não usuários. Cada contribuinte receber uma chave única para acessar as APIs diretamente não implementa SSO, não delega autorização e expõe as chaves a riscos de vazamento. Além disso, não há um provedor de identidade centralizado.