O protocolo Oauth2.0, descrito pela RFC 6749 e proposto pela...

Próximas questões
Com base no mesmo assunto
Ano: 2026 Banca: FGV Órgão: TJ-SC Prova: FGV - 2026 - TJ-SC - Analista de Sistemas |
Q4150999 Segurança da Informação
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
Alternativas

Gabarito comentado

Confira o gabarito comentado por um dos nossos professores

Gabarito: E

Fundamento decisivo: A questão exigia identificar a alternativa compatível com a RFC 6749 sobre access token e refresh token. A E é a única que relaciona o access token a limites de acesso, como escopo e tempo, e admite o uso de refresh token para obter novo access token sem nova autenticação do resource owner.

Tema central: Tokens no OAuth 2.0
Análise das alternativas
A
Errada
Ela erra na classificação dos grant types. A RFC 6749 não define apenas dois tipos de grant e não existe grant chamado "explicit"; o termo correto é "implicit", além de haver outros grant types principais na especificação.
B
Errada
O erro está na função do refresh token. Pela RFC, ele é uma credencial para obter novo access token quando o atual expira ou se torna inválido; não serve para solicitar nova autenticação pelo client.
C
Errada
A parte incompatível é exigir que o token válido dê acesso irrestrito aos recursos do servidor. No OAuth 2.0, o access token é limitado por escopo e outros atributos específicos de acesso, não por autorização ampla e irrestrita.
D
Errada
A RFC não atribui ao resource server a responsabilidade de armazenar credenciais do resource owner, nem estabelece armazenamento em salted hash. A especificação apenas situa a apresentação das credenciais junto ao authorization server, então a alternativa extrapola o texto normativo cobrado.
E
Certa
A alternativa E está de acordo com a RFC 6749 porque o access token denota escopo, duração e outros atributos específicos de acesso, e o refresh token pode ser emitido para obtenção de novos access tokens quando o atual expira ou se torna inválido, sem exigir nova autenticação do resource owner.
Pegadinha da questão
A questão explorou confusões clássicas da RFC 6749: trocar "implicit" por "explicit", tratar refresh token como mecanismo de nova autenticação e presumir que token válido significa acesso irrestrito.
Dica para questões semelhantes
  • Se a alternativa falar de refresh token, verifique se a função descrita é obter novo access token, e não reautenticar o usuário.
  • Se a alternativa falar de access token, procure menção a limites de acesso, como escopo e duração; acesso irrestrito tende a estar errado.
  • Em OAuth 2.0, confira com precisão os nomes dos grant types da RFC; troca de termos é erro técnico relevante.

Clique para visualizar este gabarito

Visualize o gabarito desta questão clicando no botão abaixo

Comentários

Veja os comentários dos nossos alunos

A - a 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. ERRADO: não é entregue diretamente para o client, mas sim por intermédio do authorization server. Além disso, a RFC 6749 são limita a 2 tipos de Grants e não existe "Explicit". São exemplos de Grant: Authorization Code, Implicit, Resource Owner Password Credentials e Client Credentials

B - os 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. ERRADO: não solicta uma nova autenticação, e sim permite que o client obtenha um novo access token diretamente junto ao authorization server sem exigir que o resource owner se autentique novamente

C - o 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. ERRADO: o acesso não é irrestrito, mas apenas aos recursos autorizados pelo resource owner

D - o 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. ERRADO: essa é uma responsabilidade do authorization server

E - 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. CORRETO

A alternativa correta é a E.

Vamos analisar cada opção no estilo da FGV, mostrando onde está o erro.

A) Incorreta ❌

"...são definidos 2 tipos de grant: explicit e authorization code."

O erro está nessa parte.

A RFC 6749 define quatro tipos principais de grant:

Authorization Code

Implicit (não "explicit")

Resource Owner Password Credentials

Client Credentials

Além disso, hoje o fluxo Implicit está praticamente em desuso por questões de segurança.

B) Incorreta ❌

"...refresh token serve para solicitar nova autenticação..."

O refresh token não realiza nova autenticação.

Ele serve para obter um novo access token sem que o usuário precise se autenticar novamente.

C) Incorreta ❌

"...token válido... e de acesso irrestrito aos recursos presentes no servidor."

O erro é dizer acesso irrestrito.

No OAuth 2.0 o acesso é limitado pelos scopes (escopos) definidos no token.

D) Incorreta ❌

"...o resource server é responsável por manter as credenciais do resource owner..."

Não.

Quem autentica o usuário e trata suas credenciais é o Authorization Server.

O Resource Server apenas protege os recursos e valida o token.

E) Correta ✅

"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 refresh tokens para novas autorizações sem necessidade de nova autenticação."

Essa é exatamente a ideia do OAuth 2.0:

Access Token possui:

escopos (scopes);

tempo de validade (expires_in).

O servidor pode emitir um Refresh Token, permitindo ao cliente obter um novo Access Token sem que o usuário precise fazer login novamente.

Resumo para decorar (FGV)

Authorization Server → autentica o usuário e emite tokens.

Resource Server → protege os recursos e aceita tokens válidos.

Access Token → acesso temporário.

Refresh Token → gera novo Access Token sem novo login.

Scopes → limitam o que pode ser acessado.

✅ Gabarito: E.

resposta do Chat.

Letra e)

Letra a) ERRADA

Existem 4 tipos: 

Authorization Code: O usuário é redirecionado para o servidor de autorização, faz login e autoriza o acesso. O servidor devolve um código temporário para a aplicação. Em seguida, o backend da aplicação troca esse código pelo access token diretamente com o servidor de autorização.

Implicit: O usuário faz login e o access token é devolvido diretamente na URL de redirecionamento para o navegador

Resource Owner Password Credentials: O usuário digita seu nome de usuário e senha diretamente na interface do cliente (aplicação).

Client Credentials: A aplicação se autentica no servidor de autorização usando suas próprias credenciais (Client ID e Client Secret), sem envolver a interação de nenhum usuário final.

Letra b) ERRADA

A principal função do refresh token é justamente evitar uma nova autenticação do resource owner (usuário) quando o access token expira, permitindo que o client obtenha um novo access token de forma transparente.

Letra c) ERRADA

"... acesso restrito ..."

Letra d) ERRADA

O responsável pelo gerenciamento de autenticação do resource owner e pela emissão dos tokens é o Authorization Server (Servidor de Autorização), e não o Resource Server.

Clique para visualizar este comentário

Visualize os comentários desta questão clicando no botão abaixo