Pular para o conteúdo principal

Questão de Segurança da Informação — OAuth — CESPE / CEBRASPE 2025

Segurança da InformaçãoOAuth
Código
ce418117
Banca
CESPE / CEBRASPE
Órgão
TRF 6
Ano
2025
Cargo
AJ TRF6

Julgue o item a seguir, relativo aos serviços de autenticação Keycloak e OAuth 2.0.

 

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.

  1. CCerto
  2. EErrado
Revelar gabarito e comentário

GabaritoE — Errado

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

OAuth 2.0: autorização delegada e acesso de terceiros

❌ ERRADO. A afirmação está incorreta porque o OAuth 2.0 não concede "acesso ilimitado" a um serviço HTTP — o acesso é sempre limitado pelo escopo (scope) e pela validade do token — e, além disso, o protocolo permite expressamente que uma aplicação de terceiros obtenha acesso por conta própria, sem a intervenção de um usuário, por meio do fluxo Client Credentials. O OAuth 2.0 é um padrão de autorização delegada (RFC 6749), no qual o acesso é concedido mediante tokens com permissões específicas e prazo de validade, e não um mecanismo de acesso irrestrito.

O OAuth 2.0 é um protocolo de autorização, não de autenticação. Ele permite que uma aplicação (o cliente) acesse recursos protegidos em nome de um usuário (o dono do recurso), sem que o usuário precise compartilhar suas credenciais com a aplicação. O fluxo típico envolve quatro atores: o dono do recurso (quem autoriza o acesso), o cliente (a aplicação que quer acessar), o servidor de autorização (que autentica o usuário e emite tokens) e o servidor de recursos (que hospeda os dados protegidos e valida os tokens).

A chave para entender o erro da afirmação está em dois pontos. Primeiro, o acesso concedido por um access token nunca é ilimitado: o token tem um tempo de vida curto e carrega escopos (scopes), que definem exatamente quais recursos e permissões o cliente pode acessar. O servidor de recursos valida o token e verifica se o escopo autoriza aquela operação específica. Segundo, o OAuth 2.0 prevê o fluxo Client Credentials, no qual a própria aplicação (um cliente confidencial, como um serviço de backend) se autentica diretamente no servidor de autorização com suas próprias credenciais e recebe um token para acessar recursos — sem que haja qualquer usuário envolvido. Esse fluxo é justamente o oposto do que a afirmação sustenta.

Vejamos um exemplo concreto: imagine um serviço de relatórios financeiros que precisa buscar dados de uma API de câmbio. Esse serviço (o cliente) pode se autenticar no servidor de autorização usando suas próprias credenciais (client_id e client_secret) e obter um token de acesso. Com esse token, ele consulta a API de câmbio (o servidor de recursos) e obtém as cotações. Não há nenhum usuário final no meio — a aplicação de terceiros obteve acesso "por conta própria", exatamente o que a afirmação nega.

A confusão que a banca explora é tratar o OAuth 2.0 como se fosse um mecanismo de acesso irrestrito, quando na verdade ele é um mecanismo de delegação controlada. O token não é uma chave-mestra; é um passe com prazo de validade e permissões limitadas. Além disso, a afirmação mistura dois conceitos: o acesso delegado (em nome do usuário) e o acesso direto da aplicação (Client Credentials). O OAuth 2.0 suporta ambos, e o segundo é justamente o que a assertiva diz que não existe.

NÃO CAIA NESSA!

A banca tenta fazer o candidato acreditar que o OAuth 2.0 só funciona com a participação de um usuário e que o token dá acesso ilimitado. Na verdade, o protocolo tem o fluxo Client Credentials, em que a aplicação acessa recursos por conta própria, e o acesso é sempre limitado por escopo e validade. Guarde isso: OAuth 2.0 = autorização delegada e controlada, nunca acesso ilimitado.

OAuth 2.0 (RFC 6749)
  • 1Autorização delegada
    • Dono do recurso
    • Cliente
    • Servidor de autorização
    • Servidor de recursos
  • 2Acesso limitado
    • Escopo (scope)
    • Validade do token
  • 3Fluxos
    • Em nome do usuário
      • Autorização com intervenção
    • Client Credentials
      • Aplicação acessa por conta própria
      • Sem usuário envolvido
LEVEL · soulevel.com.br

Alternativa E — ❌ Incorreta (Gabarito)

A afirmação está errada por dois motivos. Primeiro, o OAuth 2.0 não permite "acesso ilimitado" a um serviço HTTP: o access token tem validade e escopos que restringem o que o cliente pode fazer. Segundo, o protocolo permite expressamente que uma aplicação de terceiros obtenha acesso por conta própria, por meio do fluxo Client Credentials, no qual o cliente se autentica diretamente no servidor de autorização com suas próprias credenciais e recebe um token para acessar recursos, sem a participação de um usuário. Portanto, a assertiva está incorreta.

Gabarito: E (Errado).

Link permanente: /questoes/ce418117