{"subject_id":"3a3cc48d0099811c81aec31ecd61acfa","topico":"SSO e federação: SAML × OAuth 2.0 × OIDC","stems":["Considerando processos de autenticação e autorização relacionados ao OpenID Connect e ao OAuth 2.0, julgue os itens a seguir.","A respeito de OpenId Connect, julgue os itens subsequentes.","No que se refere a single sign‐on, Git e Keycloak, julgue os itens subsequentes.","No que diz respeito ao Oauth 2.0 e ao JSON Web Tokens (JWT), julgue os itens subsequentes.","Acerca de segurança da informação, segurança de datacenter, segurança de dispositivos e disponibilidade, julgue os itens a seguir.","No que concerne a OAuth2, JSON e Hibernate Envers, julgue os itens subsequentes.","O XYZ Digital, sistema nacional de agendamento de serviços públicos, acessado via autenticação de cidadãos para solicitação de documentos e consultas, passou por auditoria de segurança após tentativas de acesso indevido e um incidente de autenticação indevida. Após o incidente, constatou-se a utilização de única), tendo sido providenciadas a autenticação forte com multifator (MFA) e a implementação de OpenID Connect. A partir do caso hipotético precedente, julgue os itens subsequentes.","Considerando o uso do protocolo OAuth 2.0 para melhores práticas de mecanismos de autenticação, julgue os itens a seguir.","Em relação aos métodos de autenticação e seus principais protocolos, julgue os próximos itens.","A respeito da plataforma digital do Poder Judiciário brasileiro (PDPJ-Br), julgue os itens a seguir.","Acerca das tecnologias que atendem a PDPJ-Br, julgue os próximos itens.","Julgue os itens seguintes, relativos ao protocolo de autenticação OAuth 2.0.","Julgue os próximos itens, relativos a H2, Keycloak, Webhooks, Git, CD (continuous delivery) e CI (continuous integration).","Julgue o próximo item, relativo aos serviços de autenticação Keycloak.","Julgue os itens seguintes, relativos a métodos e protocolos de autenticação.","A respeito da autenticação e proteção de sistemas, julgue os itens que se seguem.","A respeito de JWT (JSON web tokens), julgue os próximos itens.","Acerca do uso do framework de autenticação OAuth 2.0, julgue o item subsequente.","Julgue os próximos itens, relativos aos serviços de autenticação Keycloak e OAuth 2.0.","Julgue os itens que se seguem, referentes a controle de acesso, gestão de identidades, serviços de autenticação e monitoramento de tráfego.","Acerca de gerenciamento de API, de RESTful e de ITIL 4, julgue os itens subsequentes.","Acerca de SAML e JWT, julgue o item a seguir.","A respeito do SAML 2.0, julgue os itens a seguir.","Com relação a integrações de sistemas de informação por meio de web services e APIs, julgue os itens a seguir.","Julgue os itens subsequentes, a respeito da interoperabilidade entre aplicações.","No que se refere a OAuth, julgue os seguintes itens.","Acerca de JWT, julgue os próximos itens.","No que se refere a autenticação e riscos de segurança, julgue os itens subsequentes."],"questions":[{"id":"0901596314c1","number":76,"stem":0,"statement":"Na especificação do OAuth 2.0 (RFC 6749), os servidores de autorização podem processar parâmetros de solicitação não reconhecidos.","answer":"E","source":{"slug":"INFRASA_26_ANALISTA","ano":2026},"explanation":{"verdict_reason":"A RFC 6749 determina o oposto: o servidor de autorização deve ignorar parâmetros de requisição não reconhecidos, tanto no endpoint de autorização quanto no de token. A regra existe para impedir que parâmetros não previstos alterem o comportamento do endpoint e para preservar a interoperabilidade entre implementações.","distortion_type":"inversao","distorted_span":"podem processar parâmetros de solicitação não reconhecidos","corrected_statement":"Na especificação do OAuth 2.0 (RFC 6749), os servidores de autorização devem ignorar parâmetros de solicitação não reconhecidos.","concept":"Parâmetros não reconhecidos devem ser ignorados","citation":"RFC 6749, seções 3.1 e 3.2","trap_note":"Ignorar × processar é a troca clássica em regras de tratamento de parâmetros. Onde a RFC escreve que o servidor deve ignorar, o item escreve que ele pode processar, e o gabarito é errado."}},{"id":"34766e9b688e","number":77,"stem":0,"statement":"No OAuth 2.0, o parâmetro max_age faz que as partes envolvidas em um processo de autorização busquem a data atual do sistema.","answer":"E","source":{"slug":"INFRASA_26_ANALISTA","ano":2026},"explanation":{"verdict_reason":"O parâmetro max_age é definido pelo OpenID Connect, não pela especificação central do OAuth 2.0, e sua função é outra: indicar o tempo máximo, em segundos, admitido desde a última autenticação do usuário final. Ultrapassado esse limite, o usuário precisa se autenticar de novo, e o instante da autenticação é informado na claim auth_time. Ele não busca a data do sistema.","distortion_type":"atribuicao_errada","distorted_span":"faz que as partes envolvidas em um processo de autorização busquem a data atual do sistema","corrected_statement":"No OpenID Connect, o parâmetro max_age indica o tempo máximo, em segundos, desde a última autenticação do usuário final, exigindo nova autenticação quando esse limite é ultrapassado.","concept":"max_age limita a idade da autenticação no OIDC","citation":"OpenID Connect Core 1.0, seção 3.1.2.1","trap_note":"Os parâmetros de identidade — max_age, prompt, nonce, acr_values — são do OpenID Connect, não do OAuth 2.0 puro. Item que os atribui ao OAuth 2.0 e ainda inventa a função erra duas vezes."}},{"id":"070a0e6ddf99","number":81,"stem":1,"statement":"Uma das vulnerabilidades do OpenID Connect é o uso de tokens não assinados para transportar atributos pessoais do usuário final.","answer":"E","source":{"slug":"STM_25","ano":2025},"explanation":{"verdict_reason":"O OpenID Connect exige o contrário: o token de identidade é um JWT que deve ser assinado com JWS, e a parte confiável tem de validar essa assinatura antes de aceitar as afirmações sobre o usuário. Foi justamente essa assinatura obrigatória que a camada OIDC acrescentou ao OAuth 2.0, cujos tokens de acesso podem ser opacos e não verificáveis pelo cliente.","distortion_type":"inversao","distorted_span":"o uso de tokens não assinados","corrected_statement":"Uma das exigências do OpenID Connect é o uso de tokens de identidade assinados para transportar atributos pessoais do usuário final.","concept":"O token de identidade do OIDC deve ser assinado (JWS)","citation":"OpenID Connect Core 1.0, seção 2","trap_note":"Item que apresenta como vulnerabilidade de um padrão exatamente aquilo que o padrão obriga a fazer está invertido. Teste sempre: a fragilidade apontada é permitida pela especificação ou proibida por ela?"}},{"id":"3d27c3cefa8a","number":82,"stem":1,"statement":"OpenID Connect é um protocolo em que provedores de identidade são capazes de lidar com os processos de autenticação de forma segura, sendo possível verificar as identidades dos usuários de aplicativos que o utilizam.","answer":"C","source":{"slug":"STM_25","ano":2025},"explanation":{"verdict_reason":"Descreve corretamente o papel do OIDC: os provedores de identidade conduzem a autenticação e emitem um token de identidade assinado, e as aplicações que confiam nesse provedor verificam a identidade do usuário sem nunca manipular as credenciais dele. Verificar identidade é justamente o serviço que a camada OIDC acrescenta ao OAuth 2.0.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"OIDC verifica identidade por meio do provedor de identidade","citation":"OpenID Connect Core 1.0","trap_note":"Autorização responde o que se pode fazer; autenticação responde quem se é. O OIDC é a camada que responde à segunda pergunta, e itens que lhe atribuem essa função tendem a ser certos."}},{"id":"678232419430","number":92,"stem":2,"statement":"Keycloak é uma ferramenta open-source que permite, em um projeto que utilize abordagem DevSecOps, implementar com segurança CI (continuous integration) e CD (continuous deployment), automatizando etapas do ciclo de desenvolvimento de software, como construção, teste e implantação.","answer":"E","source":{"slug":"STM_25","ano":2025},"explanation":{"verdict_reason":"O Keycloak é uma solução de gestão de identidades e acessos: faz autenticação única, federação de identidades, autorização e emissão de tokens por OpenID Connect, OAuth 2.0 e SAML. Automatizar construção, teste e implantação é tarefa de ferramentas de esteira, como Jenkins ou GitLab CI. O item toma um produto real e lhe atribui a função de outro domínio.","distortion_type":"atribuicao_errada","distorted_span":"implementar com segurança CI (continuous integration) e CD (continuous deployment)","corrected_statement":"Keycloak é uma ferramenta open-source que permite, em um projeto que utilize abordagem DevSecOps, implementar com segurança a autenticação única e a gestão de identidades e acessos, centralizando o login, a federação de identidades e a autorização das aplicações.","concept":"Keycloak é IAM, não ferramenta de CI/CD","citation":null,"trap_note":"Quando o item nomeia uma ferramenta conhecida e descreve corretamente uma atividade de TI, verifique se a atividade pertence ao domínio daquela ferramenta. Nos itens errados de Keycloak deste tópico o mecanismo estava certo e o produto é que não fazia aquilo."}},{"id":"9264f904ac96","number":93,"stem":3,"statement":"A utilização do JWT e de um processo de comunicação implica a autenticação e a autorização dentro de qualquer sessão.","answer":"E","source":{"slug":"TELEBRAS_25","ano":2025},"explanation":{"verdict_reason":"O JWT é apenas um formato de token: ele transporta afirmações assinadas, mas não realiza autenticação nem autorização por si. Quem autentica é o provedor que emitiu o token, e quem autoriza é a aplicação, que valida a assinatura, confere a expiração e aplica suas próprias regras de acesso. Usar JWT não implica, portanto, autenticação e autorização em qualquer sessão.","distortion_type":"generalizacao","distorted_span":"implica a autenticação e a autorização dentro de qualquer sessão","corrected_statement":"A utilização do JWT e de um processo de comunicação não implica, por si só, a autenticação e a autorização dentro de qualquer sessão.","concept":"JWT é formato de token, não mecanismo de autenticação","citation":"RFC 7519","trap_note":"Formato não é mecanismo: o JWT carrega a decisão tomada por outro componente, não decide nada. Some a isso o quantificador qualquer, que quase sempre estica a regra além do que o padrão garante."}},{"id":"430d39ed8a6e","number":94,"stem":3,"statement":"O Oauth 2.0 baseia-se em tokens de acesso e depende do TLS para garantir segurança no transporte de dados.","answer":"C","source":{"slug":"TELEBRAS_25","ano":2025},"explanation":{"verdict_reason":"As duas metades constam do padrão: o OAuth 2.0 é construído sobre tokens de acesso, que substituem as credenciais do usuário, e a RFC 6749 exige TLS nas trocas com o endpoint de autorização e com o endpoint de token. Sem TLS, o token viaja em claro e quem o interceptar passa a ser o portador, que é exatamente o modelo de segurança do bearer token.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"OAuth 2.0 depende do TLS para proteger tokens ao portador","citation":"RFC 6749, seção 1.6; RFC 6750, seção 5.3","trap_note":"O token do OAuth 2.0 é ao portador: quem tem o token tem o acesso. Por isso a confidencialidade do protocolo é integralmente delegada ao TLS, e não a mecanismos próprios."}},{"id":"e2b2647e5b03","number":94,"stem":2,"statement":"Single sign-on é uma solução de autenticação que permite que os usuários façam login uma vez utilizando um único conjunto de credenciais e acessem várias aplicações durante a mesma sessão.","answer":"C","source":{"slug":"STM_25","ano":2025},"explanation":{"verdict_reason":"É a definição canônica de SSO: um único conjunto de credenciais, uma única autenticação e acesso a várias aplicações dentro da mesma sessão. O ganho é de usabilidade e de controle centralizado; o custo é a concentração do risco em uma credencial só, que se mitiga com autenticação multifator e logout global.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Definição de single sign-on","citation":null,"trap_note":"SSO não é o mesmo que repetir a mesma senha em vários sistemas. O que caracteriza o SSO é uma sessão de identidade compartilhada e uma única autenticação, não a reutilização da credencial."}},{"id":"a03d169f7c79","number":105,"stem":4,"statement":"OAuth 2 é um protocolo que permite a autorização segura, sem revelar credenciais, enquanto JWT é um formato de token, que pode ser usado com OAuth 2 para transmitir informações de forma segura entre partes.","answer":"C","source":{"slug":"MP_CE_25_SERVIDOR","ano":2025},"explanation":{"verdict_reason":"As duas metades descrevem corretamente objetos de naturezas diferentes: o OAuth 2 é um arcabouço de autorização delegada, no qual o aplicativo recebe um token em lugar da senha do usuário, e o JWT é apenas um formato compacto de token, definido na RFC 7519. Por serem coisas de camadas distintas, um não substitui o outro: o JWT é frequentemente o formato escolhido para os tokens emitidos em um fluxo OAuth 2.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"OAuth 2 autoriza; JWT é formato de token","citation":"RFC 6749 (OAuth 2.0) e RFC 7519 (JWT)","trap_note":"Protocolo e formato não competem entre si. Quando o item põe OAuth 2 e JWT lado a lado sem trocar os papéis (autorizar × representar o token), costuma estar certo; o erro aparece quando um é apresentado como implementação, versão ou alternativa do outro."}},{"id":"40f02e01aba7","number":113,"stem":5,"statement":"OAuth2 é um padrão aberto que permite que aplicações obtenham acesso seguro às informações do usuário de outros sites, em que os tokens de acesso são credenciais usadas para acessar recursos protegidos com escopo e durações de acesso específicos, concedidos pelo proprietário do recurso e aplicados pelo servidor de recursos e pelo servidor de autorização.","answer":"C","source":{"slug":"STM_25","ano":2025},"explanation":{"verdict_reason":"Todas as peças estão nos lugares: o OAuth2 é padrão aberto de acesso delegado; o token de acesso é a credencial usada para alcançar recursos protegidos; o escopo e a duração delimitam o que e por quanto tempo; o consentimento é do proprietário do recurso; e a aplicação da restrição cabe ao servidor de autorização, ao emitir, e ao servidor de recursos, ao validar e entregar.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Escopo e validade concedidos pelo dono e aplicados pelos servidores","citation":"RFC 6749, seções 1.4 e 3.3","trap_note":"Item longo que distribui corretamente conceder, emitir e aplicar entre proprietário, servidor de autorização e servidor de recursos costuma ser certo. Confira cada verbo contra o papel antes de procurar erro em outro lugar."}},{"id":"036305b4ce20","number":115,"stem":6,"statement":"O uso de SSO pode representar um risco à segurança se não for acompanhado por mecanismos adicionais de segurança, como logout global e MFA.","answer":"C","source":{"slug":"STM_25","ano":2025},"explanation":{"verdict_reason":"O SSO concentra o acesso a várias aplicações em uma única credencial e em uma única sessão: comprometida a credencial, o atacante herda tudo de uma vez, e uma sessão que permanece aberta continua valendo em todas as aplicações. Por isso as compensações citadas são as corretas: a autenticação multifator eleva o custo de comprometer a credencial e o logout global fecha a sessão em todas as aplicações ao mesmo tempo.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Concentração de risco no SSO e controles compensatórios","citation":null,"trap_note":"Todo ganho de conveniência em identidade tem contrapartida de risco concentrado. Itens que reconhecem esse custo do SSO costumam ser certos; os que apresentam o SSO como aumento puro de segurança, sem ressalva, costumam ser errados."}},{"id":"4022c3a65025","number":116,"stem":6,"statement":"A implementação de OpenID Connect no XYZ Digital permite a autenticação federada, na qual um provedor de identidade confiável autentica o usuário em nome do sistema.","answer":"C","source":{"slug":"STM_25","ano":2025},"explanation":{"verdict_reason":"É exatamente o que a camada OIDC acrescenta: a aplicação deixa de verificar credenciais por conta própria e passa a confiar na autenticação realizada por um provedor de identidade, recebendo dele um token de identidade assinado que afirma quem é o usuário. Esse é o modelo de identidade federada.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"OIDC e autenticação federada delegada ao provedor de identidade","citation":"OpenID Connect Core 1.0","trap_note":"Federar é confiar na afirmação de um terceiro. Em qualquer protocolo federado, SAML ou OIDC, quem autentica é o provedor de identidade e quem confia é o provedor de serviços ou a parte confiável."}},{"id":"1c954aad73e7","number":57,"stem":7,"statement":"É recomendado aos clientes que implementam OAuth 2.0 usar o tipo de resposta do código de autorização em vez dos tipos de resposta que causam a emissão do token de acesso no terminal de autorização.","answer":"C","source":{"slug":"MPO_24","ano":2024},"explanation":{"verdict_reason":"É a recomendação das boas práticas de segurança do OAuth 2.0: os clientes devem usar o tipo de resposta de código de autorização em vez dos tipos de resposta que fazem o token de acesso ser emitido já no endpoint de autorização, que é o caso do fluxo implícito. O motivo é que ali o token volta pelo redirecionamento, exposto ao navegador, ao histórico e a vazamento por referenciador, e sem autenticação do cliente.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Código de autorização em vez de fluxo implícito","citation":"OAuth 2.0 Security Best Current Practice (RFC 9700)","trap_note":"As boas práticas do OAuth 2.0 apontam sempre na mesma direção: código de autorização com PKCE, token fora da URL e redirecionamento conferido exatamente. Item que recomenda o contrário disso é errado."}},{"id":"4996f187e1d4","number":58,"stem":7,"statement":"É uma recomendação adicional de segurança como melhor prática que os servidores nos quais os retornos de chamada estão hospedados exponham redirecionadores abertos, principalmente quando a aplicação estiver exposta na Internet.","answer":"E","source":{"slug":"MPO_24","ano":2024},"explanation":{"verdict_reason":"A recomendação é exatamente a oposta: os servidores que hospedam os URIs de retorno de chamada não devem expor redirecionadores abertos. Um redirecionador aberto permite ao atacante desviar o código de autorização ou o token para um destino sob seu controle, e o risco cresce quando a aplicação está exposta na Internet.","distortion_type":"inversao","distorted_span":"exponham redirecionadores abertos","corrected_statement":"É uma recomendação adicional de segurança como melhor prática que os servidores nos quais os retornos de chamada estão hospedados não exponham redirecionadores abertos, principalmente quando a aplicação estiver exposta na Internet.","concept":"Redirecionadores abertos em URIs de retorno de chamada","citation":"OAuth 2.0 Security Best Current Practice (RFC 9700)","trap_note":"Recomendação de segurança nunca manda expor, permitir ou flexibilizar. Quando o verbo da suposta boa prática afrouxa um controle, o item está invertido."}},{"id":"417171f999fc","number":59,"stem":8,"statement":"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.","answer":"E","source":{"slug":"TCE_AC_24","ano":2024},"explanation":{"verdict_reason":"A primeira parte reproduz a definição corrente do OAuth, que é dar às aplicações acesso designado seguro, mas o mecanismo apontado é o do OpenID: transmitir dados de autenticação entre consumidores e provedores de serviços. O OAuth não transporta identidade nem prova de autenticação; ele emite e transporta tokens de autorização, que dizem o que o portador pode fazer, não quem ele é.","distortion_type":"atribuicao_errada","distorted_span":"por transmitir dados de autenticação entre consumidores e provedores de serviços","corrected_statement":"O OAuth é um protocolo que fornece aos aplicativos a capacidade de acesso designado seguro por transmitir tokens de autorização entre consumidores e provedores de serviços.","concept":"OAuth autoriza; OpenID transmite dados de autenticação","citation":"RFC 6749, seção 1","trap_note":"Aqui, sim, a separação autorização × autenticação decide o item — mas repare que ela só decide quando o item descreve o mecanismo, ou seja, o que o token transporta, e não quando apenas usa a palavra autenticação como rótulo do assunto."}},{"id":"427d303c1dd6","number":60,"stem":8,"statement":"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.","answer":"C","source":{"slug":"TCE_AC_24","ano":2024},"explanation":{"verdict_reason":"O OpenID Connect Core prevê três fluxos: código de autorização, implícito e híbrido. No fluxo implícito, os tokens são devolvidos diretamente à parte confiável pelo endpoint de autorização, em um URI de redirecionamento, sem uma segunda requisição ao endpoint de token. O item apenas descreve esse fluxo previsto na especificação.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Fluxo implícito do OpenID Connect","citation":"OpenID Connect Core 1.0, seção 3.2","trap_note":"Existir na especificação e ser recomendado são coisas diferentes. O fluxo implícito existe (item certo) e ao mesmo tempo é desaconselhado pelas boas práticas de segurança (outro item certo). Leia se a frase afirma existência ou recomendação."}},{"id":"f09a64e2bdb8","number":61,"stem":9,"statement":"A autenticação na PDPJ-Br é feita por meio da solução de single sign-on baseada no Keycloack, sendo o OAuth2 o protocolo utilizado nesse processo.","answer":"C","source":{"slug":"CNJ_24","ano":2024},"explanation":{"verdict_reason":"A PDPJ-Br adota autenticação centralizada por single sign-on apoiada no Keycloak, e o protocolo empregado nessa integração é o OAuth 2.0, sobre o qual roda o OpenID Connect. A grafia Keycloack não desfaz o item: o produto e o protocolo indicados são os da plataforma.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Autenticação da PDPJ-Br: SSO com Keycloak e OAuth2","citation":null,"trap_note":"Em item sobre plataforma pública, erro de grafia de produto não é o que a banca julga. Concentre-se no par produto/protocolo: trocar o Keycloak por outro produto, ou o OAuth2 por outro protocolo, é que decidiria o item."}},{"id":"b61d7c3cd180","number":68,"stem":10,"statement":"No modelo de identidade federada, o provedor de identidades (identity provider) fornece uma identidade ao usuário após este passar por um processo de autenticação.","answer":"C","source":{"slug":"CNJ_24","ano":2024},"explanation":{"verdict_reason":"É a definição do modelo federado: o provedor de identidades conduz o processo de autenticação e, concluído esse processo, afirma a identidade do usuário ao provedor de serviços, que passa a confiar nessa afirmação. Funciona assim tanto no SAML, com asserções em XML, quanto no OpenID Connect, com o token de identidade.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Papel do provedor de identidades na identidade federada","citation":null,"trap_note":"Federação é relação de confiança: um autentica, os outros aceitam. Quem autentica nunca é o provedor de serviços, e inverter esses dois papéis é a forma mais comum de erro em identidade federada."}},{"id":"ab8c083261c8","number":69,"stem":11,"statement":"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.","answer":"E","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"O encerramento único de sessão existe e é a contrapartida natural do login único: o provedor de identidade notifica as aplicações da sessão, por canal frontal ou traseiro, para que todas encerrem o acesso de uma só vez. Afirmar que o logout precisa ser feito aplicação por aplicação nega um recurso que o modelo oferece — e é justamente por existir logout global que o risco do SSO é considerado administrável.","distortion_type":"inversao","distorted_span":"o single logout deve ser realizado individualmente","corrected_statement":"Conforme o OAuth 2.0, o single sign-on é possível mediante a implementação de sessões, e o single logout também pode ser realizado de forma global.","concept":"Single logout existe e é global","citation":null,"trap_note":"SSO e single logout andam juntos. O item vizinho, que afirmava apenas o SSO, é certo; este, que concede o SSO e nega o logout único, é errado. Quando a banca dá uma metade e nega a outra com um entretanto, é na negação que está o gabarito."}},{"id":"16ad16feca97","number":70,"stem":11,"statement":"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.","answer":"C","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"É a definição operacional do SSO: uma autenticação única passa a valer para as demais aplicações que confiam na mesma sessão de identidade, de modo que o usuário entra em uma e já está autenticado nas outras. O item não descreve mecanismo interno do OAuth 2.0, descreve o efeito do login único, que é como o padrão é empregado na prática.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Definição de single sign-on","citation":null,"trap_note":"A banca aceita atribuir o SSO ao OAuth 2.0 e marca Certo. Não recuse o item por rigor de nomenclatura; recuse-o apenas se o efeito descrito estiver errado."}},{"id":"1f8942b91e54","number":70,"stem":12,"statement":"O Keycloak é considerado uma pilha de software completa cujo objetivo principal é gerenciar a segurança em contêineres à medida que ele administra a infraestrutura de docker.","answer":"E","source":{"slug":"STJ_24","ano":2024},"explanation":{"verdict_reason":"O objetivo do Keycloak é gerenciar identidades e acessos: autenticação única, federação de identidades, autorização e emissão de tokens para aplicações e serviços. Ele pode ser executado em contêiner, mas não administra infraestrutura Docker nem tem por finalidade a segurança de contêineres, que é domínio de outras ferramentas.","distortion_type":"atribuicao_errada","distorted_span":"cujo objetivo principal é gerenciar a segurança em contêineres à medida que ele administra a infraestrutura de docker","corrected_statement":"O Keycloak é considerado uma pilha de software completa cujo objetivo principal é gerenciar identidades e acessos de aplicações e serviços, oferecendo autenticação única, federação de identidades e autorização.","concept":"Finalidade do Keycloak: gestão de identidades e acessos","citation":null,"trap_note":"Rodar em contêiner não é administrar contêineres. A banca explora essa passagem em vários produtos: o ambiente de execução do software é apresentado como se fosse o objeto que ele gerencia."}},{"id":"fc781649319d","number":71,"stem":13,"statement":"Em Keycloak, a troca de token é o processo pelo qual um cliente pode trocar um token Keycloak existente por um token externo.","answer":"C","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"A troca de token do Keycloak é exatamente isso: o cliente entrega um token que já possui e recebe outro em troca. A documentação prevê os três sentidos, isto é, trocar um token do Keycloak por outro token do Keycloak, trocar um token do Keycloak por um token externo de provedor federado e trocar um token externo por um token do Keycloak. O item descreve um desses casos previstos.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Troca de token (token exchange) no Keycloak","citation":"Documentação do Keycloak (Token Exchange); RFC 8693","trap_note":"Keycloak é servidor de identidade: tudo que ele faz gira em torno de emitir, validar, trocar e revogar tokens e de federar provedores. Item que lhe atribui tarefa de outro domínio, como esteira de CI/CD ou orquestração de contêineres, erra por atribuição."}},{"id":"9ae8ea3b38b6","number":84,"stem":14,"statement":"JSON Web Tokens é um padrão para autenticação e troca de informações que pode ser assinado usando-se um segredo ou par de chaves privadas/públicas em um cenário de autorização no qual, depois que o usuário estiver conectado, será possível observar cada solicitação e verificar se esta inclui o JWT, permitindo que o usuário acesse rotas, serviços e outros recursos.","answer":"C","source":{"slug":"TCE_AC_24","ano":2024},"explanation":{"verdict_reason":"O trecho reproduz a definição corrente do padrão: o JWT é um token que pode ser assinado com segredo compartilhado (HMAC) ou com par de chaves pública e privada (RSA, ECDSA), e o uso típico é de autorização. Emitido depois do login, ele acompanha cada requisição seguinte e a aplicação decide o acesso conferindo a assinatura e as claims. A RFC 7519 declara justamente esses dois usos: autenticação apoiada em token e troca segura de informações entre partes.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"JWT: assinatura simétrica ou assimétrica e uso pós-login","citation":"RFC 7519","trap_note":"O JWT admite tanto HMAC com segredo quanto assinatura com par de chaves. Item que restringe o JWT a apenas uma dessas opções, ou que afirma que ele é sempre cifrado, está estreitando o padrão."}},{"id":"f64d8664dc60","number":88,"stem":14,"statement":"O protocolo OAuth 2, adotado por instituições de governo para autenticação e controle dos acessos às suas APIs, permite que aplicativos obtenham acesso limitado a contas de usuários em um serviço HTTP, sem a necessidade de envio do nome de usuário e da senha.","answer":"C","source":{"slug":"TCE_AC_24","ano":2024},"explanation":{"verdict_reason":"Reproduz a definição da RFC 6749: o OAuth 2 permite que uma aplicação obtenha acesso limitado a contas de usuário em um serviço HTTP, dispensando o envio do nome de usuário e da senha ao cliente, que passa a trabalhar com um token de acesso de escopo e validade delimitados. A palavra autenticação no início não desfaz o item, porque a finalidade descrita — controlar o acesso às APIs sem entregar credenciais — é exatamente a do OAuth 2.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"OAuth 2 dá acesso limitado sem repassar credenciais","citation":"RFC 6749, seção 1","trap_note":"Neste tópico a banca usa autenticação em sentido largo e marca Certo itens que chamam o OAuth 2 de protocolo de autenticação. Não trate isso como veto: julgue o mecanismo descrito (token com escopo limitado, sem senha) e não o rótulo usado."}},{"id":"a924a7b25738","number":89,"stem":14,"statement":"Um aplicativo cliente que realiza a autenticação de um usuário mediante um servidor de autorização que adota o OpenID Connect recebe de volta um token de acesso e um token de identidade com algumas informações adicionais do usuário, seguindo o fluxo de autenticação representado a seguir.","answer":"C","source":{"slug":"TCE_AC_24","ano":2024},"explanation":{"verdict_reason":"É o resultado padrão do OpenID Connect: o servidor de autorização devolve ao cliente um token de acesso, herdado do OAuth 2.0, e um token de identidade (ID Token), que é a novidade da camada OIDC e carrega as afirmações sobre o usuário autenticado, como quem ele é e quando se autenticou. Atributos adicionais de perfil ainda podem ser buscados no endpoint UserInfo com o token de acesso.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"OIDC devolve token de acesso e token de identidade","citation":"OpenID Connect Core 1.0, seção 3.1.3.3","trap_note":"O que distingue o OIDC do OAuth 2.0 puro é o token de identidade. Item que diz que o OIDC devolve apenas o token de acesso, ou que é o token de acesso que carrega a identidade do usuário, trocou os dois."}},{"id":"55c0e1d82d5f","number":97,"stem":15,"statement":"O OpenID Connect é um protocolo de identidade simples, construído no protocolo do JSON Web Token, e permite que os aplicativos clientes confiem na autenticação executada por um provedor OpenID Connect para verificar a identidade de um usuário.","answer":"E","source":{"slug":"TCE_AC_24","ano":2024},"explanation":{"verdict_reason":"O OpenID Connect é definido como uma camada simples de identidade construída sobre o protocolo OAuth 2.0. O JSON Web Token é apenas o formato usado para representar o token de identidade que essa camada emite, ou seja, é insumo e não fundação. O restante do item, sobre o cliente confiar na autenticação executada pelo provedor, está correto.","distortion_type":"troca_de_termo","distorted_span":"construído no protocolo do JSON Web Token","corrected_statement":"O OpenID Connect é um protocolo de identidade simples, construído no protocolo OAuth 2.0, e permite que os aplicativos clientes confiem na autenticação executada por um provedor OpenID Connect para verificar a identidade de um usuário.","concept":"OIDC é camada sobre OAuth 2.0, não sobre JWT","citation":"OpenID Connect Core 1.0, resumo","trap_note":"Empilhe os três de baixo para cima: OAuth 2.0 é a base, o OpenID Connect é a camada de identidade sobre ela e o JWT é o formato do token que trafega. Trocar a base pelo formato é o erro que este tópico mais repete na parte de OIDC."}},{"id":"86571c685dd5","number":98,"stem":15,"statement":"O JSON Web Token consiste em três partes separadas por pontos: o cabeçalho, que contém informações sobre o tipo de token e o algoritmo de criptografia usado para assinar o token; o payload, que contém as informações do usuário; e a assinatura, usada para garantir que o token não tenha sido alterado.","answer":"C","source":{"slug":"TCE_AC_24","ano":2024},"explanation":{"verdict_reason":"É a estrutura do JWT: três partes codificadas em Base64URL e separadas por pontos, isto é, o cabeçalho, com o tipo do token e o algoritmo de assinatura; o payload, com as afirmações sobre o usuário e o contexto; e a assinatura, calculada sobre as duas primeiras partes, que permite detectar qualquer alteração do token.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Estrutura em três partes do JWT","citation":"RFC 7519, seção 3","trap_note":"Três partes, separadas por ponto, e só a terceira protege. O payload é apenas codificado, não cifrado: item que disser que o payload do JWT é criptografado ou ilegível está errado."}},{"id":"242c986d9263","number":103,"stem":16,"statement":"Um bom princípio de segurança de um JWT é que ele tenha um período de uso e que, após esse período, seja expirado.","answer":"C","source":{"slug":"CNJ_24","ano":2024},"explanation":{"verdict_reason":"Token de vida curta é boa prática exatamente porque o JWT é autocontido: o servidor o aceita pela assinatura, sem consultar estado, de modo que um token vazado continua valendo até expirar. A claim exp limita essa janela, e é por isso que a expiração é o principal controle de dano em JWT.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Expiração (exp) como controle de dano em JWT","citation":"RFC 7519, seção 4.1.4; RFC 8725","trap_note":"O JWT é difícil de revogar porque é validado localmente pela assinatura. Toda boa prática do tópico decorre daí: prazo curto, refresh token e escopo mínimo."}},{"id":"f09bf5415ebf","number":104,"stem":16,"statement":"JWT são usados para autenticar usuários antes que eles forneçam credenciais válidas, já que a aplicação que utiliza JWT necessita do UserID.","answer":"E","source":{"slug":"CNJ_24","ano":2024},"explanation":{"verdict_reason":"A ordem é a inversa: o usuário apresenta credenciais válidas, o servidor as verifica e só então emite o JWT, que passa a acompanhar as requisições seguintes como prova daquela autenticação já ocorrida. Um token emitido antes da verificação das credenciais não provaria coisa alguma.","distortion_type":"inversao","distorted_span":"antes que eles forneçam credenciais válidas","corrected_statement":"JWT são usados para autenticar usuários depois que eles forneçam credenciais válidas, já que a aplicação que utiliza JWT necessita do UserID.","concept":"O JWT é emitido depois da autenticação, não antes","citation":"RFC 7519","trap_note":"Inversão temporal é um dos padrões mais produtivos do tópico: antes/depois, emite/valida, concede/recebe. Reconstrua a linha do tempo do fluxo antes de julgar."}},{"id":"0e88a1cb9a4c","number":105,"stem":17,"statement":"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.","answer":"C","source":{"slug":"STJ_24","ano":2024},"explanation":{"verdict_reason":"As duas afirmações são do padrão. O refresh token existe para obter novos tokens de acesso quando o anterior expira, sem nova interação do usuário, e o OpenID Connect é definido como uma camada de identidade construída sobre o OAuth 2.0, que acrescenta autenticação ao arcabouço de autorização por meio do token de identidade.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Refresh token e OIDC como camada sobre OAuth 2.0","citation":"RFC 6749, seção 1.5; OpenID Connect Core 1.0","trap_note":"A ordem das camadas é fixa: OAuth 2.0 embaixo, OpenID Connect em cima. Qualquer item que inverta isso, ou que construa o OIDC sobre outra coisa (JWT, SAML), está errado."}},{"id":"582ea1037980","number":105,"stem":18,"statement":"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.","answer":"C","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"É a definição literal da RFC 6749: tokens de acesso são credenciais usadas para acessar recursos protegidos, e o token de acesso é uma cadeia de caracteres que representa uma autorização emitida ao cliente. Essa cadeia costuma ser opaca para o cliente, que não precisa interpretá-la, apenas apresentá-la ao servidor de recursos.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Definição de token de acesso na RFC 6749","citation":"RFC 6749, seção 1.4","trap_note":"O token de acesso representa autorização, não identidade. Quem representa identidade é o token de identidade do OpenID Connect. Item que faz o token de acesso carregar quem é o usuário trocou os dois."}},{"id":"5e93d3f49a97","number":106,"stem":19,"statement":"O protocolo RADIUS pode ser utilizado em conjunto com o SSO (single sign-on) e keycloak para fornecer autenticação segura, enquanto os protocolos SAML, OAuth2 (RFC 6749) e OpenID Connect são utilizados para facilitar a integração e a interoperabilidade entre diferentes serviços de autenticação e autorização.","answer":"C","source":{"slug":"TRT10_24","ano":2024},"explanation":{"verdict_reason":"Os dois blocos estão corretos e são complementares: o RADIUS é protocolo de AAA em rede, usado para autenticação centralizada e integrável a soluções de SSO como o Keycloak, enquanto SAML, OAuth 2.0 e OpenID Connect são os padrões de federação e de delegação que permitem a interoperabilidade entre serviços distintos de autenticação e autorização. A numeração indicada para o OAuth 2.0 também está correta.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"RADIUS em AAA de rede × SAML, OAuth 2.0 e OIDC em federação","citation":"RFC 6749; RFC 2865","trap_note":"Guarde o número: OAuth 2.0 é a RFC 6749. É praticamente o único número que este tópico cobra, e ele aparece tanto dentro de item certo quanto nos enunciados."}},{"id":"02dc2dd40f01","number":107,"stem":18,"statement":"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.","answer":"E","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"O resumo da RFC 6749 diz o contrário nas duas metades: o arcabouço permite acesso limitado, nunca ilimitado, e permite sim que a aplicação de terceiros obtenha acesso por conta própria, que é o que faz a concessão client credentials. Token válido não significa acesso irrestrito, porque é o escopo que delimita o alcance do token.","distortion_type":"inversao","distorted_span":"obtenha acesso ilimitado a um serviço HTTP","corrected_statement":"A estrutura de autorização do OAuth 2.0 permite que uma aplicação obtenha acesso limitado a um serviço HTTP se houver token válido, e também permite que uma aplicação de terceiros obtenha acesso por conta própria.","concept":"Acesso limitado por escopo e concessão client credentials","citation":"RFC 6749, resumo e seção 4.4","trap_note":"Limitado é palavra estrutural do OAuth 2.0: está na definição e é o que o escopo implementa. Trocar limitado por ilimitado, irrestrito ou total resolve o item sem ler o resto."}},{"id":"6e525729f1cb","number":129,"stem":20,"statement":"OAuth é um protocolo de autorização utilizado na API RESTful que permite que aplicativos obtenham acesso limitado a recursos, por meio da inserção do nome e da senha do usuário no cabeçalho da solicitação a ser enviada.","answer":"E","source":{"slug":"SEPLAG_CE_24","ano":2024},"explanation":{"verdict_reason":"A primeira parte está correta, pois o OAuth concede acesso limitado a recursos, mas o mecanismo descrito é o oposto do protocolo. O OAuth existe precisamente para que o aplicativo cliente nunca receba nem transmita o nome de usuário e a senha: o que viaja no cabeçalho Authorization é um token de acesso previamente emitido pelo servidor de autorização.","distortion_type":"inversao","distorted_span":"por meio da inserção do nome e da senha do usuário no cabeçalho da solicitação a ser enviada","corrected_statement":"OAuth é um protocolo de autorização utilizado na API RESTful que permite que aplicativos obtenham acesso limitado a recursos, por meio da inserção de um token de acesso no cabeçalho da solicitação a ser enviada.","concept":"OAuth trafega token, não credenciais do usuário","citation":"RFC 6749, seção 1; RFC 6750","trap_note":"Sem revelar credenciais, sem envio de nome de usuário e senha, sem compartilhamento de senhas: essa cláusula aparece nos itens certos do tópico. Quando o item põe a senha do usuário circulando, ele nega a razão de ser do OAuth."}},{"id":"7ff14aa7749c","number":138,"stem":21,"statement":"O SAML, assim como o JWT, utiliza JSON para formatar as afirmações de segurança.","answer":"E","source":{"slug":"SEPLAG_CE_24","ano":2024},"explanation":{"verdict_reason":"O SAML é um padrão baseado em XML: suas asserções, requisições e respostas são documentos XML, assinados com XML Signature. Quem formata afirmações em JSON é o JWT. A diferença de formato é o contraste mais cobrado entre os dois padrões, e o item o desfaz ao igualá-los.","distortion_type":"troca_de_termo","distorted_span":"assim como o JWT, utiliza JSON","corrected_statement":"O SAML, diferentemente do JWT, utiliza XML para formatar as afirmações de segurança.","concept":"SAML usa XML; JWT usa JSON","citation":"OASIS SAML 2.0 Core","trap_note":"SAML é XML e é verboso; JWT é JSON e é compacto. Essa é praticamente a única propriedade do SAML que o tópico cobra: se o item disser que o SAML usa JSON, acabou."}},{"id":"5095a6ae7ece","number":65,"stem":22,"statement":"O SAML é considerado o principal padrão de autenticação, sendo o OAuth2 a sua correspondente implementação.","answer":"E","source":{"slug":"BCB_24","ano":2023},"explanation":{"verdict_reason":"SAML e OAuth 2.0 são padrões independentes, criados por organismos distintos e com finalidades distintas: o SAML troca asserções de autenticação em XML entre provedor de identidade e provedor de serviços, enquanto o OAuth 2.0 é um arcabouço de autorização delegada baseado em tokens. Um não implementa o outro nem é versão do outro. Implementações de SAML são produtos como Shibboleth e ADFS.","distortion_type":"atribuicao_errada","distorted_span":"sendo o OAuth2 a sua correspondente implementação","corrected_statement":"O SAML é considerado o principal padrão de autenticação federada, sendo o OAuth2 um padrão independente, voltado à autorização delegada.","concept":"SAML e OAuth 2.0 são padrões independentes","citation":null,"trap_note":"Padrão × implementação é uma dupla que a banca gosta de embaralhar. Antes de aceitar que A implementa B, verifique se os dois não são apenas padrões distintos, que resolvem problemas diferentes."}},{"id":"109cd93b88da","number":66,"stem":22,"statement":"O sujeito, o provedor de identidade e o provedor de serviços são as partes envolvidas em um processo do tipo autenticação, considerando-se o SAML e o início de sessão única (SSO).","answer":"C","source":{"slug":"BCB_24","ano":2023},"explanation":{"verdict_reason":"São exatamente os três papéis do SAML: o sujeito, que é o usuário cuja identidade se afirma; o provedor de identidade, que autentica e emite a asserção; e o provedor de serviços, que consome a asserção e libera o acesso. O SSO em SAML nasce de o provedor de serviços confiar na asserção emitida pelo provedor de identidade em vez de autenticar o usuário por conta própria.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Sujeito, provedor de identidade e provedor de serviços no SAML","citation":"OASIS SAML 2.0 Core","trap_note":"No SAML há três partes; no OAuth 2.0 há quatro (proprietário do recurso, cliente, servidor de autorização e servidor de recursos). Item que aplica o elenco de um protocolo no outro erra por aí."}},{"id":"c19da61e85db","number":67,"stem":23,"statement":"OAuth é um padrão de tecnologia aberta de delegação de acesso, projetado para permitir que um site ou aplicativo acesse recursos hospedados por outros aplicativos na Web em nome de um usuário, permitindo o compartilhamento de conteúdos sem a necessidade de compartilhamento de senhas.","answer":"C","source":{"slug":"DATAPREV_23","ano":2023},"explanation":{"verdict_reason":"É a definição consagrada do OAuth: padrão aberto de delegação de acesso, pelo qual um sítio ou aplicativo acessa, em nome do usuário, recursos hospedados em outra aplicação, sem que a senha do usuário seja compartilhada. A delegação se materializa no token de acesso, com escopo e prazo definidos.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"OAuth como delegação de acesso sem compartilhar senha","citation":"RFC 6749","trap_note":"Delegação de acesso é o resumo do OAuth em três palavras. Sempre que o item preservar acesso em nome do usuário e sem compartilhar senha, o núcleo está certo."}},{"id":"437af023f1e4","number":72,"stem":24,"statement":"OAuth, que é um protocolo utilizado para autorizar aplicações web, desktop, mobile e dispositivos em geral, não separa o papel do cliente do papel do proprietário do recurso.","answer":"E","source":{"slug":"SEFIN_FORTALEZA_CE_23","ano":2023},"explanation":{"verdict_reason":"A RFC 6749 abre afirmando exatamente o contrário: o OAuth introduz uma camada de autorização e separa o papel do cliente do papel do proprietário do recurso. Essa separação é a razão de existir do protocolo, pois é ela que permite ao aplicativo agir em nome do usuário sem possuir as credenciais dele. O item nega a característica que define o OAuth.","distortion_type":"inversao","distorted_span":"não separa o papel do cliente do papel do proprietário do recurso","corrected_statement":"OAuth, que é um protocolo utilizado para autorizar aplicações web, desktop, mobile e dispositivos em geral, separa o papel do cliente do papel do proprietário do recurso.","concept":"OAuth separa cliente e proprietário do recurso","citation":"RFC 6749, seção 1","trap_note":"Boa parte dos itens errados deste tópico é a negação literal de uma frase da RFC 6749. Quando a afirmação põe um não colado à característica central de um protocolo, desconfie antes de qualquer outra coisa."}},{"id":"c10d4fd0fd1c","number":73,"stem":24,"statement":"Para alcançar a interoperabilidade entre aplicações, é necessário adotar padrões abertos e comuns, tais quais serviços web, REST, JSON, XML, OAuth e OpenID Connect.","answer":"C","source":{"slug":"SEFIN_FORTALEZA_CE_23","ano":2023},"explanation":{"verdict_reason":"Interoperabilidade depende de padrões abertos e amplamente adotados, e a lista é toda dessa natureza: serviços web e REST como estilos de integração, JSON e XML como formatos de representação, OAuth e OpenID Connect como padrões abertos de autorização delegada e de autenticação federada. O item não atribui função errada a nenhum deles, apenas os arrola como padrões comuns.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Padrões abertos como base da interoperabilidade","citation":null,"trap_note":"Item que apenas arrola padrões costuma ser certo: o erro raramente está na lista e quase sempre na descrição da função de cada um. Só marque Errado se algum dos citados aparecer com o papel de outro."}},{"id":"4bf48427a4fd","number":63,"stem":25,"statement":"A parte com capacidade de conceder acesso aos recursos protegidos é o servidor de recurso.","answer":"E","source":{"slug":"BANRISUL_22","ano":2022},"explanation":{"verdict_reason":"A RFC 6749 define o proprietário do recurso como a entidade capaz de conceder acesso a um recurso protegido, normalmente o usuário final. O servidor de recursos é quem hospeda o recurso e atende requisições acompanhadas de token de acesso: ele verifica a autorização, mas não a concede. Conceder é do dono, não de quem guarda.","distortion_type":"troca_de_termo","distorted_span":"o servidor de recurso","corrected_statement":"A parte com capacidade de conceder acesso aos recursos protegidos é o proprietário do recurso.","concept":"Proprietário do recurso × servidor de recursos","citation":"RFC 6749, seção 1.1","trap_note":"Decore o elenco do OAuth 2.0 pelo verbo: o proprietário concede, o servidor de autorização emite, o servidor de recursos entrega, o cliente pede. Quase todo item de papéis se resolve trocando o substantivo pelo verbo."}},{"id":"f006aae690b0","number":64,"stem":25,"statement":"Consideradas as etapas do fluxo de autenticação do protocolo, é correto afirmar que, sendo o token válido, a primeira etapa ocorre com a solicitação, pelo cliente, de autorização para o acesso aos recursos e a última, com o servidor de recursos servindo o recurso solicitado.","answer":"C","source":{"slug":"BANRISUL_22","ano":2022},"explanation":{"verdict_reason":"Descreve corretamente as pontas do fluxo abstrato da RFC 6749: ele começa com o cliente solicitando autorização ao proprietário do recurso e termina com o servidor de recursos, depois de validar o token apresentado, entregando o recurso pedido. Entre uma ponta e outra ficam a concessão de autorização, a troca da concessão por token de acesso no servidor de autorização e a apresentação do token ao servidor de recursos.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Ordem do fluxo abstrato do OAuth 2.0","citation":"RFC 6749, seção 1.2","trap_note":"A ordem nunca muda: pedir autorização, obter a concessão, trocá-la por token, apresentar o token, receber o recurso. Itens de fluxo são certos quando respeitam esse encadeamento e errados quando adiantam o token para antes do consentimento."}},{"id":"253d8a253f45","number":65,"stem":25,"statement":"O servidor de autenticação tem como função autenticar o usuário, ao passo que o dono do recurso é responsável pela emissão dos tokens.","answer":"E","source":{"slug":"BANRISUL_22","ano":2022},"explanation":{"verdict_reason":"Quem emite os tokens é o servidor de autorização, depois de autenticar o proprietário do recurso e obter dele o consentimento. O dono do recurso concede a autorização, mas não emite nada. O item mantém a primeira metade correta e troca o emissor pelo concedente.","distortion_type":"inversao","distorted_span":"o dono do recurso é responsável pela emissão dos tokens","corrected_statement":"O servidor de autenticação tem como função autenticar o usuário, ao passo que o servidor de autorização é responsável pela emissão dos tokens.","concept":"O servidor de autorização emite tokens; o dono apenas consente","citation":"RFC 6749, seção 1.1","trap_note":"Conceder × emitir é a troca de papéis mais repetida do tópico, e ela quase sempre vem na segunda metade da frase, com a primeira metade correta para dar credibilidade."}},{"id":"34cb3899156d","number":66,"stem":26,"statement":"Reserved claims possuem o atributo não obrigatório iss (Issuer), que se refere à origem do token.","answer":"C","source":{"slug":"BANRISUL_22","ano":2022},"explanation":{"verdict_reason":"As claims registradas da RFC 7519 — iss, sub, aud, exp, nbf, iat e jti — são todas de uso opcional: o padrão reserva os nomes e define o significado, mas não obriga a presença de nenhuma delas. A claim iss identifica o emissor do token, isto é, a origem que o produziu. O item acerta tanto o caráter não obrigatório quanto o significado.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Claims registradas do JWT são opcionais; iss é o emissor","citation":"RFC 7519, seção 4.1.1","trap_note":"Reservado não quer dizer obrigatório: a RFC reserva o nome, não exige o campo. É esse o ponto que o item testa, e o erro habitual vem da analogia com campos obrigatórios de cabeçalho."}},{"id":"7261efe7a608","number":68,"stem":26,"statement":"Entre os diferentes tipos de claims em payloads, os public claims são utilizados para compartilhar informações entre aplicações.","answer":"E","source":{"slug":"BANRISUL_22","ano":2022},"explanation":{"verdict_reason":"A função descrita é a das private claims, que são as afirmações personalizadas, criadas para compartilhar informações entre as partes que concordam em utilizá-las. As public claims são as definidas livremente por quem usa JWT mas que, para evitar colisão, devem ser registradas no IANA JSON Web Token Registry ou receber nome resistente a colisão, como um URI. O item dá ao tipo público a definição do tipo privado.","distortion_type":"troca_de_termo","distorted_span":"os public claims","corrected_statement":"Entre os diferentes tipos de claims em payloads, os private claims são utilizados para compartilhar informações entre aplicações.","concept":"Private claims × public claims no payload do JWT","citation":"RFC 7519, seções 4.2 e 4.3","trap_note":"São três tipos de claim: registered (nomes reservados na RFC), public (livres, porém registradas ou com nome resistente a colisão) e private (acordadas entre as partes). Quando o item fala em compartilhar informação entre partes que combinam entre si, é private."}},{"id":"73d4d69f7c2d","number":63,"stem":27,"statement":"No contexto de OAuth 2, o servidor de autorização deve obrigar a autenticação explícita do proprietário do recurso e prover a ele informações sobre o cliente, o escopo e a vida útil da autorização solicitada.","answer":"C","source":{"slug":"SERPRO_21","ano":2021},"explanation":{"verdict_reason":"É transcrição da recomendação da RFC 6749 sobre representação indevida do cliente: o servidor de autorização deve exigir autenticação explícita do proprietário do recurso e apresentar a ele informações sobre o cliente, o escopo e a duração da autorização solicitada. A tela de consentimento existe por isso, pois sem ela o usuário autorizaria às cegas e um cliente poderia se passar por outro.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Consentimento informado no servidor de autorização","citation":"RFC 6749, seção 10.2","trap_note":"Quem autentica o proprietário do recurso e colhe o consentimento é sempre o servidor de autorização, nunca o cliente nem o servidor de recursos. Guarde o trio cliente, escopo e vida útil: é o conteúdo obrigatório da tela de consentimento."}}]}