Title: Redes e Segurança / Autenticação e seus mecanismos
Tags: Redes_e_Segurança Resumo
On every note of this deck, unless a note says otherwise:
tldr: - Mecanismos de autenticação implementam o princípio de autenticidade com controle de acesso e se agrupam em 3 fatores:
- Algo que você sabe: segredo memorizado (ex.: senha).
- Algo que você tem: posse de um objeto/meio (ex.: token, crachá, smart card).
- Algo que você é: característica biométrica (ex.: impressão digital, íris/retina, voz, face); é tratado como mais robusto em geral.
- Autenticação envolve também autorização e auditabilidade (AAA):
- Authorization (autorização): mesmo autenticado, o usuário pode ter permissões diferentes (ex.: ler diretório mas não alterar/criar).
- Accounting/Auditabilidade: registro das ações (logs) para rastrear falhas/atos indevidos e associar responsabilidades.
- O conjunto forma AAA = Authentication, Authorization, Accounting.
- 2FA (autenticação forte / dois fatores):
- Divide a autenticação em duas etapas e exige combinação entre os fatores (sabe / tem / é).
- Exemplo típico: usuário+senha (sabe) + código via SMS/e-mail/app (tem).
- O código atua como “chave de sessão” (válido por um período; a cada login gera-se um novo).
- Benefício: mesmo com senha vazada, o invasor tende a falhar sem o segundo fator.
- Exemplos citados: BB Code, Steam Guard, Gmail (e em geral aplicações web modernas).
- MFA (multifator):
- Mesmo princípio do 2FA, mas com 2 ou mais fatores.
- MFA Adaptativa (contextual):
- Ajusta dinamicamente o rigor conforme risco e comportamento.
- Parâmetros avaliados: localização, dispositivo, horário, tipo de rede (privada/pública), número de falhas de login.
- Exige verificações adicionais em cenários suspeitos (ex.: local desconhecido → SMS/biometria).
- SSO (Single Sign-On) e Single Sign-Off:
- SSO: uma autenticação permite acessar múltiplos sistemas/serviços sem repetir login (integra sistemas independentes).
- Em ambiente corporativo, comumente relacionado a LDAP; em cenários simples, pode usar cookies no navegador.
- Single Sign-Off: “deslogar” de forma integrada no sentido inverso.
- SAML 2.0 (Security Assertion Markup Language):
- Padrão aberto (não “uma tecnologia”) para troca de credenciais/assertions entre:
  - IdP (Identity Provider) e SP (Service Provider).
- Usado para SSO em ambientes corporativos; transações geralmente em XML.
- Define 3 papéis:
  1. Principal (tipicamente o usuário humano)
  2. IdP (Provedor de Identidades)
  3. SP (Provedor de Serviços)
- Fluxo básico: Principal solicita recurso ao SP → SP consulta IdP → IdP autentica o Principal → IdP envia atributos/assertions ao SP → SP decide acesso.
- O SAML não impõe método de autenticação no IdP: pode ser login/senha, MFA, e integrar com RADIUS, LDAP, Active Directory, ou identidades de terceiros (ponte conceitual para OAuth).
- Exemplo prático citado: Gov.br/Acesso.gov como login único federado:
  - Níveis de confiabilidade:
  - Bronze: e-mail + perguntas (cruzamento de bases) + login/senha.
  - Prata: verificação por documentos (físicos/digitais).
  - Ouro: biometria (com base biométrica, ex.: TSE).
  - Serviços definem o nível exigido conforme sensibilidade (ex.: consulta simples pode aceitar bronze; transação crítica pode exigir ouro).
- OAuth 2.0 (autorização delegada e login integrado):
- Padrão originado no setor privado (mencionado Google/Twitter) para permitir que um serviço acesse recursos do usuário via tokens, após consentimento.
- Fluxo conceitual: o usuário autoriza → o cliente obtém código → troca por token → usa token para acessar recursos protegidos.
- Define 4 papéis:
  1. Resource Owner: usuário/dono dos dados que concede acesso.
  2. Resource Server: API que hospeda recursos (pública como Google/Facebook/Twitter ou restrita).
  3. Authorization Server: autentica e emite tokens (ex.: Access Token), frequentemente no formato Bearer Token com claims; exige uso de HTTPS (token vai no header HTTP).
  4. Client: aplicação que solicita acesso (ex.: app web/browser).
- Etapas descritas (1 a 6): pedido de autorização → consentimento → envio ao Authorization Server → emissão de token → acesso ao Resource Server com token → retorno de dados ao Client (ex.: foto, e-mail, drive etc.).
- Detalhes cobrados em provas sobre OAuth 2.0:
- Tipos de clientes:
  - Confidenciais: possuem client secret e conseguem protegê-lo (ex.: integrações internas/servidor-servidor).
  - Públicos: não conseguem manter segredo (ex.: apps móveis, apps no browser).
- Tipos de tokens:
  - Bearer Token: quem possui o token acessa; risco: se roubado, pode ser usado por terceiros.
  - Sender-constrained (Mutual TLS): vincula token à TLS mútua; Resource Server verifica certificado do cliente; inclui hash do certificado (ex.: em JWT); exige PKI e aumenta complexidade.
  - ID Token: dados de identificação do usuário (não é para acesso a recursos protegidos).
  - Refresh Token: usado para obter novos access tokens sem novo login.
- Refresh Token (renovação):
  - String usada para obter novo access token sem interação do usuário (após autorização inicial).
  - Pode existir com expires_in (expiração do access token); refresh é opcional/configurável.
  - Risco: se roubado (especialmente em cliente público), atacante pode se passar pelo cliente.
  - Exemplo de renovação: POST no endpoint de token com grant_type=refresh_token + refresh token (+ credenciais do cliente se necessário).
- JWT (boas práticas de segurança/configuração e tokens curtos):
- Segurança: usar algoritmos seguros (HS256/RS256), proteger chaves, expiração curta (exp), revogação, validação de assinatura/claims, HTTPS, minimizar claims, validar emissor (iss).
- Configuração: claims padrão (iss, sub, aud, exp), bibliotecas confiáveis, rotação de chaves, escopos/permissões, monitoramento/logs, política de renovação.
- Tokens sem estado de curta duração: preferir curta duração, renovar via endpoint seguro, usar refresh token com armazenamento/transporte seguros, checar expiração no servidor; melhora desempenho e escalabilidade.
- Biometria (algo que você é):
- Definição: identificar unicamente por características físicas ou comportamentais (BIO + METRIA).
- Referência histórica: Francis Galton; em 1892 (no texto), sistema moderno de impressões digitais usado amplamente por polícia.
- Exemplos: impressão digital, palma, face, retina/íris (texto diferencia: retina = fundo do olho; íris = anéis coloridos), voz.
- Propriedades desejadas: universalidade, singularidade, permanência, mensurabilidade.
- Etapas do sistema biométrico: captura → extração → comparação (match contra base).
- Autenticadores móveis e OTP por app (QR code):
- Serviço gera QR code para vincular conta ao app; depois o acesso depende de aprovação/código do app.
- Códigos são dinâmicos e mudam tipicamente a cada 30 segundos.
- HOTP e TOTP (OTP para MFA):
- Geram código curto (tipicamente 6 a 8 dígitos) a partir de segredo compartilhado (seed) + parâmetro variável, via HMAC (SHA-1/256/512) e truncagem.
- HOTP: variável é contador (evento); exige sincronização de contadores e janela de aceitação (janela grande aumenta risco; pequena aumenta rejeição).
- TOTP: variável é tempo em passos (tipicamente 30s); depende de sincronização de relógio (aceita passo atual e adjacentes); boas práticas: NTP confiável, tolerância de passos e telemetria.
- O seed é o fator de posse real; o OTP é efêmero. Ameaça principal: força bruta online → usar rate-limiting/bloqueio progressivo/detecção.
- Operação: HOTP é útil offline/assíncrono, mas sofre com descompasso de contador; TOTP tende a ser padrão por simplicidade, mas depende do relógio.
- Ambos não são resistentes a phishing (phishing-relay); mitigação: vinculação de contexto, push com number matching e, idealmente, FIDO2/WebAuthn.
- Palavras-chave: HOTP=contador, TOTP=tempo; ambos dependem de segredo + HMAC; espaço pequeno de códigos exige controles de tentativa; OTP não é o segredo.
- OpenID Connect (OIDC):
- Camada sobre OAuth voltada à verificação de identidade (autenticação) integrada ao Authorization Server.
- Características: autenticação baseada em tokens, autorização por declarações/claims, abordagem descentralizada, simples/flexível, segura (criptografia), interoperável; opera via API/REST e é multiplataforma.
- Keycloak:
- Ferramenta open source de IAM (gestão de identidade e acesso), baseada em API REST.
- Recursos: telas de login customizáveis, recuperação de senha, termos de uso, pouca/nenhuma codificação, MFA, isolamento da aplicação da camada de autenticação, visualização de tokens, SSO, usa OAuth 2.0 + OpenID, banco próprio, integra com AD/LDAP.
link: https://documentacao.online/estudos/j2b8.html
title: Autenticação e seus mecanismos

front: CESPE / CEBRASPE - 2022 - TCE-SC - Auditor Fiscal de Controle Externo - Ciência da Computação No controle de acesso, somente os usuários que tenham sido especificamente autorizados podem usar e receber acesso às redes e aos seus serviços.
response: Certo
comment: Exatamente pessoal. É importante sempre lembrar essa diferença básica da autenticação e autorização.
Other fields (not shown on cards):
back: Certo - Exatamente pessoal. É importante sempre lembrar essa diferença básica da autenticação e autorização.

front: Ano: 2021 Banca: CESPE / CEBRASPE Órgão: SEFAZ-CE Códigos de verificação de um sistema de autenticação de dois fatores podem ser enviados por email ou gerados por um aplicativo autenticador instalado no dispositivo móvel do usuário.
response: Certo
comment: Exatamente pessoal. Típica questão conceito. Veremos mais à frente algumas questões mais práticas sobre o funcionamento desses aplicativos? Mas tenho certeza que muitos de vocês já usaram, como o Google Authenticator, por exemplo, ou algum serviço semelhante, onde são geradas senhas para cada usuário. Agora é importante destacar que aqui nós temos o modelo de algo que você sabe, com algo que você possui.
Other fields (not shown on cards):
back: Certo - Exatamente pessoal. Típica questão conceito. Veremos mais à frente algumas questões mais práticas sobre o funcionamento desses aplicativos? Mas tenho certeza que muitos de vocês já usaram, como o Google Authenticator, por exemplo, ou algum serviço semelhante, onde são geradas senhas para cada usuário. Agora é importante destacar que aqui nós temos o modelo de algo que você sabe, com algo que você possui.

front: Ano: 2021 Banca: CESPE / CEBRASPE Órgão: PG-DF Para acessar a intranet corporativa, um colaborador informa seu CPF, senha pessoal e um código enviado para o seu celular cadastrado. O mecanismo de reforço implementado nessa intranet para confirmar a identidade do usuário contra acessos indevidos é a autenticação:
A) biométrica;
B) Kerberos;
C) Oauth2;
D) 2FA;
E) Openid.
response: Alternativa D
comment: Conforme nós vimos pessoal, há a necessidade de conhecimento de algo que VOCÊ SABE (CPF + senha), com ALGO QUE VOCÊ POSSUI (celular). Logo, temos aí o 2FA.
Other fields (not shown on cards):
back: Alternativa D - Conforme nós vimos pessoal, há a necessidade de conhecimento de algo que VOCÊ SABE (CPF + senha), com ALGO QUE VOCÊ POSSUI (celular). Logo, temos aí o 2FA.

front: Ano: 2020 Banca: CESPE / CEBRASPE Órgão: SEFAZ-AL Identificação e autenticação são requisitos de segurança da informação que consistem em identificar usuários do sistema e verificar as suas identidades, como pré-requisito para permitir o acesso desses usuários ao sistema.
response: Certo
comment: A dinâmica é sempre essa pessoal. A autenticação é o ato final de reconhecimento do usuário ou sistema. Fato é que, para autenticar, devemos identificar. E esse processo pode acontecer de diferentes formas. Ainda, após o processo de identificação e autenticação, temos a autorização, recebendo esses dois pré-requisitos.
Other fields (not shown on cards):
back: Certo - A dinâmica é sempre essa pessoal. A autenticação é o ato final de reconhecimento do usuário ou sistema. Fato é que, para autenticar, devemos identificar. E esse processo pode acontecer de diferentes formas. Ainda, após o processo de identificação e autenticação, temos a autorização, recebendo esses dois pré-requisitos.

front: Ano: 2024 Banca: CESPE / CEBRASPE Órgão: TCDF Os tokens de acesso devem ser lidos e interpretados pelo cliente OAuth, que é o público-alvo do token.
response: Errado
comment: Há uma série de propriedades de tokens de acesso que são fundamentais para o modelo de segurança do OAuth. Os tokens de acesso não devem ser lidos ou interpretados pelo cliente OAuth. O cliente OAuth não é o público-alvo do token.
Other fields (not shown on cards):
back: Errado - Há uma série de propriedades de tokens de acesso que são fundamentais para o modelo de segurança do OAuth. Os tokens de acesso não devem ser lidos ou interpretados pelo cliente OAuth. O cliente OAuth não é o público-alvo do token.

front: Ano: 2024 Banca: CESPE / CEBRASPE Órgão: TCDF Os tokens Sender-constrained exigem que, para usar o token de acesso, o cliente OAuth prove, de alguma forma, a posse de uma chave privada, de modo que o token de acesso por si só não seja utilizável.
response: Certo
comment: Exatamente a camada adicional de segurança que comentamos em nossa teoria, que incorpora a infraestrutura de chaves públicas e certificados digitais, com a posse da chave privada..
Other fields (not shown on cards):
back: Certo - Exatamente a camada adicional de segurança que comentamos em nossa teoria, que incorpora a infraestrutura de chaves públicas e certificados digitais, com a posse da chave privada..

front: Ano: 2021 Banca: CESPE / CEBRASPE Órgão: SEFAZ-AL O uso de senhas ou a adoção de identificação física, como biometrias, são formas de autenticação para fins de identificação única e exclusiva de usuários.
response: Certo
comment: Pessoal, a questão retrata, de fato, as finalidades de senhas associadas a biometrias. A exclusividade, como vimos é um princípio da biometria. No trecho, vimos o termo SINGULARIDADE.
Other fields (not shown on cards):
back: Certo - Pessoal, a questão retrata, de fato, as finalidades de senhas associadas a biometrias. A exclusividade, como vimos é um princípio da biometria. No trecho, vimos o termo SINGULARIDADE.

front: Ano: 2021 Banca: CESPE / CEBRASPE Órgão: PG-DF Uma das condições para a autenticação é que o sinal biométrico apresenta correspondência exata entre o sinal biométrico recebido pelo sistema e o gabarito armazenado.
response: Errado
comment: Pessoal, vimos que existem os modelos comportamentais, certo? Esses modelos, também são sinais biométricos e trabalham com referências variáveis, mas dentro de um padrão aceitável, com taxa de similaridade e equivalência alto. Agora, dizer que o gabarito tem que ser exato, não é uma verdade para sua generalização.
Other fields (not shown on cards):
back: Errado - Pessoal, vimos que existem os modelos comportamentais, certo? Esses modelos, também são sinais biométricos e trabalham com referências variáveis, mas dentro de um padrão aceitável, com taxa de similaridade e equivalência alto. Agora, dizer que o gabarito tem que ser exato, não é uma verdade para sua generalização.

front: CESPE – TJ-SE/Analista Judiciário – Segurança da Informação/2014 Os métodos de autenticação comumente empregados fundamentam-se na clássica divisão entre o que você sabe (senha ou número PIN); o que você tem (token ou um smart card); e o que você é (íris, retina e digitais).
response: Certo
comment: Conforme vimos, de fato, estes são os três principais métodos.
Other fields (not shown on cards):
back: Certo - Conforme vimos, de fato, estes são os três principais métodos.

front: FGV - 2022 - TRT - 13ª Região (PB) - Técnico Judiciário - Tecnologia da Informação Marcia decidiu padronizar o mecanismo de autenticação de suas APIs RESTful e armazenar com segurança as credenciais de usuários e suas respectivas permissões. Para isso, ela deseja utilizar uma ferramenta de código aberto. A ferramenta que tem por principal finalidade o gerenciamento de identidade e acesso que Márcia deve escolher é
A JBoss.
B Keycloak.
C Kibana.
D RabbitMQ.
E Wildfly.
response: Alternativa B
comment: Temos aí pessoal uma questão que traz a forma de abordagem da solução KeyCloak. Apenas para validarmos as outras tecnologias/ferramentas: JBoss - Um servidor de aplicação Java EE de código aberto, desenvolvido pela Red Hat. Oferece uma plataforma para construir, implementar e executar aplicações empresariais. Suporte a diversas tecnologias, como EJB, CDI, JPA e JSF. Kibana: Uma ferramenta de visualização de dados e interface de usuário do Elastic Stack. Permite explorar, analisar e visualizar dados armazenados no Elasticsearch. Utilizada para monitoramento, análise de logs e business intelligence. RabbitMQ: Um message broker de código aberto que implementa o protocolo Advanced Message Queuing Protocol (AMQP). Facilita a comunicação entre aplicações através de mensagens assíncronas. Oferece alta disponibilidade e escalabilidade. Wildfly: Anteriormente conhecido como JBoss AS, é um servidor de aplicação Java EE de código aberto. Desenvolvido pela Red Hat, permite a criação e implantação de aplicações empresariais. Suporta diversas tecnologias, como EJB, CDI, JPA e JSF.
Other fields (not shown on cards):
back: Alternativa B - Temos aí pessoal uma questão que traz a forma de abordagem da solução KeyCloak. Apenas para validarmos as outras tecnologias/ferramentas: JBoss - Um servidor de aplicação Java EE de código aberto, desenvolvido pela Red Hat. Oferece uma plataforma para construir, implementar e executar aplicações empresariais. Suporte a diversas tecnologias, como EJB, CDI, JPA e JSF. Kibana: Uma ferramenta de visualização de dados e interface de usuário do Elastic Stack. Permite explorar, analisar e visualizar dados armazenados no Elasticsearch. Utilizada para monitoramento, análise de logs e business intelligence. RabbitMQ: Um message broker de código aberto que implementa o protocolo Advanced Message Queuing Protocol (AMQP). Facilita a comunicação entre aplicações através de mensagens assíncronas. Oferece alta disponibilidade e escalabilidade. Wildfly: Anteriormente conhecido como JBoss AS, é um servidor de aplicação Java EE de código aberto. Desenvolvido pela Red Hat, permite a criação e implantação de aplicações empresariais. Suporta diversas tecnologias, como EJB, CDI, JPA e JSF.

front: CESPE / CEBRASPE - 2025 - TRF - 6ª REGIÃO - Analista Judiciário – Área: Apoio Especializado – Especialidade: Tecnologia da Informação A estrutura de autorização do OAuth 2.0 permite que uma aplicação obtenha acesso ilimitado a um serviço HTTP se houver token válido, mas não permite que uma aplicação de terceiros obtenha acesso por conta própria.
response: Errado
comment: A estrutura de autorização do OAuth 2.0 permite que aplicações de terceiros obtenham acesso limitado a recursos em nome de um usuário, mas não acesso ilimitado.
Other fields (not shown on cards):
back: Errado - A estrutura de autorização do OAuth 2.0 permite que aplicações de terceiros obtenham acesso limitado a recursos em nome de um usuário, mas não acesso ilimitado.

front: CESPE / CEBRASPE - 2025 - TRF - 6ª REGIÃO - Analista Judiciário – Área: Apoio Especializado – Especialidade: Tecnologia da Informação Em Keycloak, a troca de token é o processo pelo qual um cliente pode trocar um token Keycloak existente por um token externo.
response: Certo
comment: Em Keycloak, a troca de token permite que um token válido seja trocado por um token de outro sistema, facilitando a integração com sistemas externos. Isso quer dizer que é possível integrar com sistemas de tokens como do Google, Microsoft e outros.
Other fields (not shown on cards):
back: Certo - Em Keycloak, a troca de token permite que um token válido seja trocado por um token de outro sistema, facilitando a integração com sistemas externos. Isso quer dizer que é possível integrar com sistemas de tokens como do Google, Microsoft e outros.

front: CESPE / CEBRASPE - 2025 - TRF - 6ª REGIÃO - Analista Judiciário – Área: Apoio Especializado – Especialidade: Tecnologia da Informação De acordo com a especificação OAuth 2.0, o token de acesso, credencial utilizada para acessar recursos protegidos, é uma string que representa uma autorização emitida para o cliente.
response: Certo
comment: No OAuth 2.0, o token de acesso é a credencial usada para acessar recursos protegidos. Ele é uma string gerada pelo servidor de autorização e associada a um conjunto de permissões (escopos) definidas para o cliente. Esse token representa uma autorização concedida para um cliente, e é essencial para autenticar a comunicação entre o cliente e os servidores de recursos.
Other fields (not shown on cards):
back: Certo - No OAuth 2.0, o token de acesso é a credencial usada para acessar recursos protegidos. Ele é uma string gerada pelo servidor de autorização e associada a um conjunto de permissões (escopos) definidas para o cliente. Esse token representa uma autorização concedida para um cliente, e é essencial para autenticar a comunicação entre o cliente e os servidores de recursos.

front: CESPE / CEBRASPE - 2025 - TRF - 6ª REGIÃO - Analista Judiciário – Área: Apoio Especializado – Especialidade: Tecnologia da Informação Segundo o OAuth 2.0, o SSO (single sign-on) ocorre quando um usuário, ao fazer login em um aplicativo, automaticamente faz login em outros aplicativos.
response: Certo
comment: No OAuth 2.0, o conceito de Single Sign-On (SSO) permite que o usuário faça login em um aplicativo e, automaticamente, seja autenticado em outros aplicativos conectados. Isso proporciona uma experiência mais fluida para o usuário e é amplamente utilizado em ambientes corporativos para facilitar a gestão de múltiplas autenticações.
Other fields (not shown on cards):
back: Certo - No OAuth 2.0, o conceito de Single Sign-On (SSO) permite que o usuário faça login em um aplicativo e, automaticamente, seja autenticado em outros aplicativos conectados. Isso proporciona uma experiência mais fluida para o usuário e é amplamente utilizado em ambientes corporativos para facilitar a gestão de múltiplas autenticações.

front: CESPE / CEBRASPE - 2025 - TRF - 6ª REGIÃO - Analista Judiciário – Área: Apoio Especializado – Especialidade: Tecnologia da Informação Conforme o OAuth 2.0, o single sign-on é possível mediante a implementação de sessões, entretanto o single logout deve ser realizado individualmente.
response: Errado
comment: Embora o OAuth 2.0 permita a implementação de Single Sign-On, o conceito de Single Logout não é trivial e precisa ser tratado separadamente, uma vez que o logout de um serviço pode não afetar outros serviços. O OAuth 2.0 não define explicitamente um método para implementar o logout único entre todos os serviços, o que requer soluções adicionais.
Other fields (not shown on cards):
back: Errado - Embora o OAuth 2.0 permita a implementação de Single Sign-On, o conceito de Single Logout não é trivial e precisa ser tratado separadamente, uma vez que o logout de um serviço pode não afetar outros serviços. O OAuth 2.0 não define explicitamente um método para implementar o logout único entre todos os serviços, o que requer soluções adicionais.

front: CESPE / CEBRASPE - 2025 - PC-DF - Gestor de Apoio as Atividades Policiais Civis - Especialidade: Analista de Informática: Rede de Computadores No contexto do protocolo OpenID Connect, um identity token representa o resultado de um processo de autenticação, com assinatura digital, que contém declarações descritoras do usuário e os detalhes da autenticação, como, por exemplo, informações sobre como e quando o usuário foi autenticado.
response: Certo
comment: O identity token no OpenID Connect representa um resultado de autenticação, assinado digitalmente, contendo informações sobre o usuário e detalhes da autenticação, como método e tempo de autenticação.
Other fields (not shown on cards):
back: Certo - O identity token no OpenID Connect representa um resultado de autenticação, assinado digitalmente, contendo informações sobre o usuário e detalhes da autenticação, como método e tempo de autenticação.

front: CESPE / CEBRASPE - 2024 - TSE - Analista Judiciário – Área: Apoio Especializado – Especialidade: Tecnologia da Informação A autenticação multifatorial, um dos controles listados no Microsoft SDL (security development lifecycle), adiciona uma segunda camada crítica de segurança aos logins, a fim de proteger todos os usuários, especialmente os administradores.
response: Certo
comment: Essa é a base do princípio funcional esperado para o MFA.
Other fields (not shown on cards):
back: Certo - Essa é a base do princípio funcional esperado para o MFA.

front: CESPE / CEBRASPE - 2024 - STJ - Analista Judiciário - Área: Apoio Especializado - Especialidade: Suporte em Tecnologia da Informação O OAuth 2.0 utiliza refresh tokens para obter novos tokens de acesso, sem pedir ao usuário para fazer login novamente, e serve de base para o OpenID Connect, que adiciona uma camada de autenticação sobre o protocolo de autorização.
response: Certo
comment: O OAuth 2.0 permite que aplicações acessem recursos sem expor credenciais do usuário. O refresh token renova o token de acesso sem precisar autenticar novamente. O OpenID Connect usa o OAuth 2.0 como base, adicionando autenticação ao modelo de autorização.
Other fields (not shown on cards):
back: Certo - O OAuth 2.0 permite que aplicações acessem recursos sem expor credenciais do usuário. O refresh token renova o token de acesso sem precisar autenticar novamente. O OpenID Connect usa o OAuth 2.0 como base, adicionando autenticação ao modelo de autorização.

front: CESPE / CEBRASPE - 2024 - TC-DF - Auditor de Controle Externo - Área Especializada - Especialidade: Tecnologia da Informação - Orientação Microinformática de TI JWT (JSON web tokens) é um método de token criptografado com chave pública baseada em biometria de autenticação e, portanto, pode funcionar integrado ao celular de um usuário.
response: Errado
comment: O JWT não é criptografado por padrão, mas assinado digitalmente para garantir sua autenticidade. Além disso, não está diretamente relacionado à biometria, sendo usado para autenticação baseada em tokens, não credenciais biométricas.
Other fields (not shown on cards):
back: Errado - O JWT não é criptografado por padrão, mas assinado digitalmente para garantir sua autenticidade. Além disso, não está diretamente relacionado à biometria, sendo usado para autenticação baseada em tokens, não credenciais biométricas.

front: CESPE / CEBRASPE - 2024 - TC-DF - Auditor de Controle Externo - Área Especializada - Especialidade: Tecnologia da Informação - Orientação Microinformática de TI Usar SMS para envio de tokens de acesso e de autenticação é uma técnica que garante sigilo contra interceptação do token por terceiros, já que o SMS trafega cifrado fim a fim, logo, mesmo que o token consiga ser interceptado, ele será inútil para um atacante, por estar criptografado.
response: Errado
comment: SMS não é seguro para autenticação, pois trafega sem criptografia ponta a ponta e pode ser interceptado por ataques como SIM Swap. A recomendação é usar aplicativos autenticadores ou chaves físicas em vez de SMS para MFA.
Other fields (not shown on cards):
back: Errado - SMS não é seguro para autenticação, pois trafega sem criptografia ponta a ponta e pode ser interceptado por ataques como SIM Swap. A recomendação é usar aplicativos autenticadores ou chaves físicas em vez de SMS para MFA.

front: CESPE / CEBRASPE - 2025 - TRF - 6ª REGIÃO - Técnico Judiciário – Área: Apoio Especializado – Especialidade: Suporte Técnico Em OAuth 2.0, um servidor de recursos que aceita apenas solicitações assinadas exige que cada solicitação assinada seja identificável de maneira exclusiva e seja processada uma única vez.
response: Certo
comment: Essas são as garantias esperadas de todo processo de troca de tokens.
Other fields (not shown on cards):
back: Certo - Essas são as garantias esperadas de todo processo de troca de tokens.

front: CESPE / CEBRASPE - 2024 - TCE-AC - Analista de Tecnologia da Informação - Área: Segurança da Informação O MFA pode utilizar o fator de inerência, conhecido como autenticação por biometria, por ser uma das opções mais seguras disponíveis, considerando a sua dificuldade de ser contornada.
response: Certo
comment: O termo inerente está associado a algo intrínseco da pessoa, ou seja, algo como característica biométrica.
Other fields (not shown on cards):
back: Certo - O termo inerente está associado a algo intrínseco da pessoa, ou seja, algo como característica biométrica.

front: CESPE / CEBRASPE - 2024 - TCE-AC - Analista de Tecnologia da Informação - Área: Segurança da Informação A especificação do OpenID Connect determina que a autenticação pode ocorrer, entre outras formas, em fluxo implícito, no qual tokens são devolvidos diretamente para a parte confiável, em um URI (Uniform Resource Identifier) de redirecionamento.
response: Certo
comment: A especificação do OpenID Connect define múltiplos fluxos de autenticação, entre eles o fluxo implícito. Nesse fluxo, os tokens (como o ID token e, eventualmente, o access token) são retornados diretamente para a parte confiável, embutidos em um URI de redirecionamento, sem a necessidade de uma troca adicional de código. Essa abordagem permite que o cliente receba os tokens de forma imediata após a autenticação.
Other fields (not shown on cards):
back: Certo - A especificação do OpenID Connect define múltiplos fluxos de autenticação, entre eles o fluxo implícito. Nesse fluxo, os tokens (como o ID token e, eventualmente, o access token) são retornados diretamente para a parte confiável, embutidos em um URI de redirecionamento, sem a necessidade de uma troca adicional de código. Essa abordagem permite que o cliente receba os tokens de forma imediata após a autenticação.

front: CESPE / CEBRASPE - 2024 - TCE-AC - Analista de Tecnologia da Informação - Área: Segurança da Informação O OAuth é um protocolo que fornece aos aplicativos a capacidade de acesso designado seguro por transmitir dados de autenticação entre consumidores e provedores de serviços.
response: Errado
comment: Ele não trafega dados de autenticação. Todo processo é feito via Tokens de autorização sem a necessidade de compartilhamento das credenciais. Ao final, o recurso também é trafegado de forma protegida.
Other fields (not shown on cards):
back: Errado - Ele não trafega dados de autenticação. Todo processo é feito via Tokens de autorização sem a necessidade de compartilhamento das credenciais. Ao final, o recurso também é trafegado de forma protegida.

front: CEBRASPE (CESPE) - Ana Sist (EMPREL)/EMPREL/2023 Em situações de gerenciamento de acesso de usuários a sistemas críticos, o uso de ferramentas de segundo fator de autenticação e gerenciamento de acesso privilegiado é restrito aos administradores do sistema.
response: Errado
comment: O uso de ferramentas de segundo fator de autenticação e gerenciamento de acesso privilegiado não se restringe apenas aos administradores do sistema, mas pode ser estendido a outros usuários que acessam sistemas críticos, dependendo da política de segurança da organização.
Other fields (not shown on cards):
back: Errado - O uso de ferramentas de segundo fator de autenticação e gerenciamento de acesso privilegiado não se restringe apenas aos administradores do sistema, mas pode ser estendido a outros usuários que acessam sistemas críticos, dependendo da política de segurança da organização.

front: CEBRASPE (CESPE) - Ana Sist (EMPREL)/EMPREL/2023 No Single Sign-On, a funcionalidade em que as informações de login e senha permitem um melhor controle da equipe de TI é
a) a autenticação multifator.
b) o gerenciamento interno de credenciais.
c) a velocidade na recuperação de senhas.
d) o ponto único para reinserir senha.
e) a melhor aplicação da política de senha.
response: Alternativa B
comment: No Single Sign-On, o gerenciamento interno de credenciais é a funcionalidade que permite um melhor controle da equipe de TI, pois centraliza o gerenciamento das credenciais dos usuários, facilitando o controle de acesso e a revogação de permissões. Vejam que a questão não restringe qualquer aspecto de função ou privilégio.
Other fields (not shown on cards):
back: Alternativa B - No Single Sign-On, o gerenciamento interno de credenciais é a funcionalidade que permite um melhor controle da equipe de TI, pois centraliza o gerenciamento das credenciais dos usuários, facilitando o controle de acesso e a revogação de permissões. Vejam que a questão não restringe qualquer aspecto de função ou privilégio.