O protocolo Oauth2.0, descrito pela RFC 6749 e proposto pela...
Com relação ao protocolo Oauth2.0, como definido pelo RFC 6749, é correto afirmar que
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.
- 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