Segurança da Informação · FCC · 2026 | Questão sqc-fc077575

Segurança da InformaçãoAutenticação

Código: fc077575
Banca: FCC
Órgão: SEFAZ-SP
Ano: 2026
Nível: Superior

Cargo: Auditor Fiscal da Receita Estadual - AFRE - Tecnologia da Informação e Comunicação - Conhecimentos Especificos (P3)

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 OpenlD 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 OpenlD 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”.

SSO e Protocolos de Autenticação - Portal do Contribuinte

Gabarito: letra C. O cenário exige SSO, delegação segura de autorização e obtenção de informações do perfil do cidadão (nome, CPF). A combinação de OpenID Connect sobre OAuth 2.0 com o fluxo Authorization Code e PKCE atende perfeitamente: OpenID Connect adiciona autenticação e obtenção de claims ao OAuth 2.0, o fluxo Authorization Code é seguro para aplicações web, e o PKCE protege contra ataques de interceptação do código de autorização. O gov.br como provedor de identidade (IdP) centraliza a autenticação.

Alternativa A — ❌ Incorreta

Autenticação básica HTTP com SSL/TLS não é SSO. As credenciais são armazenadas em sessão no servidor, o que não delega autorização a terceiros (gov.br) e não fornece um mecanismo padronizado para obter informações de perfil do usuário. Além disso, a autenticação básica é menos segura que OAuth/OpenID Connect.

Alternativa B — ❌ Incorreta

O fluxo Client Credentials do OAuth 2.0 é usado para autenticação de aplicações servidoras (machine-to-machine), não para autenticação de usuários finais. Portanto, não permite obter informações do perfil do cidadão nem realiza autenticação do contribuinte.

Alternativa C — ✅ Correta ⟵ GABARITO

OpenID Connect (OIDC) é uma camada de identidade sobre OAuth 2.0. O fluxo Authorization Code com PKCE é recomendado para clientes públicos (aplicações web) e garante que o código de autorização não seja interceptado. O gov.br atua como provedor de identidade, autenticando o cidadão e fornecendo claims (nome, CPF) para personalização. Isso implementa SSO com segurança e delegação de autorização.

Alternativa D — ❌ Incorreta

OpenID Connect utiliza JSON Web Tokens (JWT) e não assertions XML; a troca de assertions XML é típica do protocolo SAML, não do OIDC. Além disso, a autenticação baseada em certificados digitais não é o padrão para fluxo de usuário final em portal web; seria mais complexo e inadequado para o cenário descrito.

Alternativa E — ❌ Incorreta

API Keys estáticas são compartilhadas entre sistemas, não entre usuários. Não há autenticação do contribuinte nem SSO. Cada chave seria fixa, sem renovação, vulnerável a vazamentos. Não atende aos requisitos de segurança e obtenção de perfil.

PEGA ESSA DICA!

Para questões de SSO com obtenção de atributos do usuário, lembre-se: OpenID Connect (sobre OAuth 2.0) é o padrão moderno. O fluxo Authorization Code é para aplicações com backend; PKCE é obrigatório para públicos. Já OAuth 2.0 puro serve apenas para autorização (escopos), não autenticação. Erros comuns: confundir Client Credentials (máquina a máquina) com autenticação de usuário, ou achar que SAML (XML) é a mesma coisa que OIDC.

Link permanente: /questoes/fc077575