Pular para o conteúdo principal

Questão de Segurança da Informação — Segurança na Internet — FGV 2026

Segurança da InformaçãoSegurança na Internet
Código
gp007226
Banca
FGV
Órgão
TJ-SC
Ano
2026
Cargo
Analista de Sistemas
O protocolo Oauth2.0, descrito pela RFC 6749 e proposto pela Internet Engineering Task Force (IETF), busca reduzir a necessidade de compartilhamento de credenciais de autenticação (como senhas ou biometria) do detentor de um recurso (chamados de resource owner) diretamente com os sistemas que precisam do credenciamento (chamados de clients). Nesse protocolo, é utilizado um servidor de autorização (chamado authorization server) que emite tokens de acesso aos clients, mediante autorização dos resource owners. Dessa forma, as credenciais são apresentadas apenas ao servidor de autorização e não a cada client.

Com relação ao protocolo Oauth2.0, como definido pelo RFC 6749, é correto afirmar que
  1. Aa authorization grant é entregue pelo resource owner para o client e representa a autorização do detentor para que o client possa acessar o recurso protegido. No Oauth2.0, são definidos 2 tipos de grant: explicit e authorization code.
  2. Bos tokens de acesso (access token) devem garantir acesso por tempo limitado ao recurso protegido. Um refresh token serve para solicitar nova autenticação pelo client após expiração do token de acesso.
  3. Co acesso ao recurso protegido é concedido pelo servidor do recurso (resource server) ao client, apenas se esse apresentar um token de acesso válido, não expirado e de acesso irrestrito aos recursos presente no servidor.
  4. Do servidor de recursos (resource server) é o responsável por manter as credenciais do resource owner secretas e íntegras, devendo armazená-las em forma de salted hash.
  5. Eao emitir um token de acesso, o servidor deve descrever no mesmo o limite de acesso ao recurso, incluindo escopo e tempo, além de poder emitir tokens de refresh para novas autorizações sem necessidade de nova autenticação.
Revelar gabarito e comentário

GabaritoE — ao emitir um token de acesso, o servidor deve descrever no mesmo o limite de acesso ao recurso, incluindo escopo e tempo, além de poder emitir tokens de refresh para novas autorizações sem necessidade de nova autenticação.

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

Protocolo OAuth 2.0 (RFC 6749)

Gabarito: letra E. No OAuth 2.0, ao emitir um access token, o servidor de autorização especifica seu escopo e tempo de validade, e pode emitir um refresh token para obter novos access tokens sem necessidade de reautenticação do resource owner. Essa é a descrição correta do funcionamento.

A banca testa o conhecimento dos principais conceitos do OAuth 2.0: tipos de authorization grant, funções do access token e refresh token, e responsabilidades dos servidores.

Alternativa A — ❌ Incorreta

Afirma que existem apenas dois tipos de authorization grant: explicit e authorization code. Na verdade, a RFC 6749 define quatro tipos principais: authorization code, implicit (depreciado), resource owner password credentials, e client credentials. Além disso, o termo "explicit" não é utilizado; o correto é "implicit" (que é um fluxo distinto). A authorization grant não é entregue diretamente pelo resource owner ao client; o client obtém o grant por meio da interação com o authorization server após autorização do resource owner.

Alternativa B — ❌ Incorreta

A primeira parte está correta: access tokens devem ter validade limitada. Porém, a descrição do refresh token está errada: ele serve para obter um novo access token sem envolver novamente o resource owner, e não para "solicitar nova autenticação". A autenticação já ocorreu; o refresh token renova a autorização sem reautenticação.

Alternativa C — ❌ Incorreta

O acesso ao recurso protegido é concedido pelo resource server mediante apresentação de um access token válido, mas jamais com "acesso irrestrito" — os tokens possuem escopo definido (scope) que limita os recursos e operações permitidas.

Alternativa D — ❌ Incorreta

O authorization server é o responsável por armazenar e validar as credenciais do resource owner, não o resource server. Este apenas valida os tokens de acesso. A menção a "salted hash" é pertinente ao armazenamento de senhas, mas a afirmação atribui função ao servidor errado.

Alternativa E — ✅ Correta ⟵ GABARITO

Conforme a RFC 6749, o access token deve conter informações sobre seu escopo e tempo de validade, e o servidor de autorização pode emitir um refresh token que permite ao client obter novos access tokens sem nova autorização do resource owner, desde que o refresh token esteja válido.

NÃO CAIA NESSA!

A alternativa B confunde a finalidade do refresh token (renovar token) com uma nova autenticação. Já na alternativa A, o erro está nos tipos de grant listados e no nome "explicit". Na prova, lembre-se: refresh token = novo access token, não nova autenticação; implicit e authorization code são apenas dois dos quatro fluxos.

MNEMÔNICO
CID
CConfidencialidade (dados acessíveis só a quem é autorizado)IIntegridade (dados exatos, consistentes e não alterados indevidamente)DDisponibilidade (informação/sistemas acessíveis quando necessário)
Segurança da Informação - Princípios/Tríade CID

Gabarito: letra E.

Link permanente: /questoes/gp007226