Pular para o conteúdo principal

Questão de Segurança da Informação — Autenticação — CESPE / CEBRASPE 2026

Segurança da InformaçãoAutenticação
Código
ce228188
Banca
CESPE / CEBRASPE
Órgão
SEMA-AM
Ano
2026
Nível
Superior
Cargo
Analista Ambiental - Especialidade: Análise de Redes
Uma equipe de TI da SEMA/AM está projetando a arquitetura de autenticação de um conjunto de APIs internas acessadas por aplicações web e móveis. A solução deverá: (i) permitir que aplicativos clientes obtenham acesso a recursos protegidos em nome do usuário, sem expor a senha ao serviço consumidor; (ii) padronizar a autenticação única (SSO) entre múltiplas aplicações, com entrega de informações de identidade em formato de token; (iii) suportar autenticação forte com segundo fator (2FA) baseada em aplicativo autenticador ou token físico, integrada ao fluxo de login. Considerando os requisitos de governança definidos no SGSI da organização, alinhado à NBR ISO/IEC 27001, bem como as recomendações de segurança sobre autenticação robusta e controle de acesso, a equipe deve avaliar algumas opções de desenho.Na situação hipotética precedente, a solução de autenticação que melhor atende, em conjunto, às três necessidades apresentadas consiste na arquitetura em que
  1. Acada microsserviço possua seu próprio banco de senhas e tokens proprietários, combinando autenticação por senha com 2FA por SMS, sem um provedor de identidade central.
  2. Bum provedor de identidade central aplique 2FA e exponha fluxos OAuth 2.0 com OpenID Connect, emitindo tokens de identidade em formato JWT para viabilizar o SSO.
  3. Cas APIs exijam certificados digitais de cliente para autenticação mútua TLS, dispensando tokens, e o segundo fator de autenticação seja aplicado apenas na emissão dos certificados.
  4. Da autenticação combine biometria local em dispositivos móveis e sessões por cookies na Web, sem usar protocolos de delegação ou tokens de identidade padronizados.
  5. Eum servidor de autorização central com OAuth 2.0 emita tokens de acesso, mas a autenticação de usuários permaneça descentralizada e independente em cada aplicação.
Revelar gabarito e comentário

GabaritoB — um provedor de identidade central aplique 2FA e exponha fluxos OAuth 2.0 com OpenID Connect, emitindo tokens de identidade em formato JWT para viabilizar o SSO.

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

Análise da solução de autenticação para APIs

Gabarito: letra B. A alternativa B descreve corretamente uma arquitetura com provedor de identidade central que aplica 2FA, utiliza os fluxos OAuth 2.0 com OpenID Connect e emite tokens JWT para viabilizar o SSO — atendendo simultaneamente aos três requisitos: delegação de acesso sem exposição de senha, autenticação única e suporte a segundo fator.

Alternativa A — ❌ Incorreta

Cada microsserviço com seu próprio banco de senhas e tokens proprietários contraria o requisito de SSO (não há identidade centralizada) e expõe senhas em cada serviço, ferindo a necessidade de não expor a senha ao consumidor. Além disso, 2FA por SMS é menos seguro, mas mesmo que fosse aceitável, a falta de um provedor central inviabiliza o SSO.

Alternativa B — ✅ Correta ⟵ GABARITO

A solução com provedor de identidade (IdP) central atende:

  • (i) OAuth 2.0 permite que o cliente obtenha um token de acesso em nome do usuário sem jamais ver a senha, através do fluxo de authorization code.

  • (ii) OpenID Connect (camada de identidade sobre OAuth 2.0) emite tokens de identidade JWT, padronizando a informação do usuário e permitindo SSO entre aplicações que confiam no IdP.

  • (iii) O IdP pode integrar 2FA (como TOTP via aplicativo autenticador ou hardware token) no fluxo de login, conforme requisito.

Alternativa C — ❌ Incorreta

Certificados digitais de cliente para autenticação mútua TLS (mTLS) são robustos, mas o requisito de delegação (i) não é atendido: a autenticação é por certificado, não há fluxo de delegação de identidade. O SSO com tokens padronizados não se aplica (certificados não são tokens JWT). O 2FA na emissão dos certificados não se integra ao fluxo de login online, inviabilizando o requisito (iii).

Alternativa D — ❌ Incorreta

Biometria local em dispositivos móveis e sessões por cookies na Web são mecanismos específicos de cada plataforma. Não há protocolos de delegação (como OAuth) nem tokens padronizados; o SSO não é garantido sem um provedor central e sem tokens interoperáveis. O requisito (i) talvez seja atendido, mas a ausência de delegação e SSO falha nos itens (ii) e (iii) (o 2FA não é integrado ao fluxo de login).

Alternativa E — ❌ Incorreta

Um servidor de autorização central com OAuth 2.0 que emite tokens de acesso atende parcialmente (i) e (ii), mas o enunciado destaca que a autenticação de usuários permanece descentralizada e independente em cada aplicação. Isso quebra o SSO (requisito ii) e impossibilita a integração centralizada de 2FA (requisito iii). Além disso, sem um provedor de identidade que unifique a autenticação, o 2FA teria que ser implementado separadamente em cada app.

Conclusão: A alternativa B é a única que contempla integralmente delegação sem senha, SSO via tokens JWT e autenticação forte com 2FA integrado.

Link permanente: /questoes/ce228188