Questão de Redes de Computadores — Segurança de Redes — FGV 2024
Redes de Computadores›Segurança de Redes
Código
fg098579
Banca
FGV
Órgão
TJ-MS
Ano
2024
Nível
Superior
Cargo
Técnico de Nível Superior - Analista de Sistemas Computacionais - Web Designer
O servidor OAuth2 do TJMS recebeu a seguinte requisição no endpoint de token:POST /token HTTP/1.1Host: auth-tjms.jus.brContent-Type: application/x-www-form-urlencodedgrant_type=client_credentials&client_id=client_id&client_secret=client_secretDe acordo com a especificação do OAuth2, a requisição OAuth2 acima é:
Ainválida, pois há parâmetros obrigatórios ausentes;
Binválida, pois utiliza o método POST ao invés do GET;
Cválida, e os parâmetros obrigatórios estão presentes;
Dinválida, pois utiliza o HTTP/1.1 ao invés do HTTP/2.0;
Einválida, pois há parâmetros com valores não permitidos.
Revelar gabarito e comentário▾
GabaritoC — válida, e os parâmetros obrigatórios estão presentes;
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: Fluxo Client Credentials
Gabarito: letra C. A requisição é válida, pois o fluxo client credentials do OAuth 2.0 exige exatamente os parâmetros presentes: grant_type=client_credentials, client_id e client_secret, enviados via método POST com Content-Type: application/x-www-form-urlencoded — todos os parâmetros obrigatórios estão presentes e com valores permitidos (RFC 6749, seção 4.4).
O OAuth 2.0 define quatro fluxos de autorização (grants), cada um com seus parâmetros obrigatórios. O fluxo client credentials é usado quando o próprio cliente (a aplicação) é o dono dos recursos — não há usuário final envolvido. Nesse fluxo, o cliente se autentica diretamente no servidor de autorização usando suas credenciais (client_id e client_secret) e recebe um token de acesso em troca.
A especificação (RFC 6749, seção 4.4.2) determina que a requisição ao endpoint de token deve incluir:
grant_type com valor client_credentials (obrigatório);
scope (opcional);
As credenciais do cliente (client_id e client_secret) podem ser enviadas no corpo da requisição ou via header de autenticação HTTP Basic.
O método HTTP correto é o POST, com o corpo no formato application/x-www-form-urlencoded. A versão do protocolo HTTP (1.1 ou 2.0) é irrelevante para a validade da requisição OAuth2.
A pegadinha desta questão está em confundir o fluxo client credentials com o fluxo authorization code, que exige parâmetros adicionais como redirect_uri e code. No fluxo client credentials, esses parâmetros não são necessários — a requisição apresentada está completa e correta.
Afirma que há parâmetros obrigatórios ausentes. No fluxo client credentials, os únicos parâmetros obrigatórios são grant_type, client_id e client_secret — todos presentes na requisição. O parâmetro scope é opcional. A alternativa confunde o fluxo client credentials com o fluxo authorization code, que exige redirect_uri e code.
Alternativa B — ❌ Incorreta
Afirma que o método POST é inválido e que deveria ser GET. A especificação OAuth 2.0 (RFC 6749) exige o método POST para o endpoint de token, com o corpo no formato application/x-www-form-urlencoded. O método GET não é utilizado para requisições de token, pois as credenciais seriam expostas na URL.
Alternativa C — ✅ Correta ⟵ GABARITO
A requisição é válida e contém todos os parâmetros obrigatórios para o fluxo client credentials: grant_type=client_credentials, client_id e client_secret. O método POST e o Content-Type estão corretos. Não há parâmetros ausentes nem valores não permitidos.
Alternativa D — ❌ Incorreta
Afirma que o HTTP/1.1 é inválido e que deveria ser HTTP/2.0. A versão do protocolo HTTP não é um requisito do OAuth 2.0 — a especificação não impõe nenhuma versão específica. Tanto HTTP/1.1 quanto HTTP/2.0 são aceitos.
Alternativa E — ❌ Incorreta
Afirma que há parâmetros com valores não permitidos. Todos os valores presentes são válidos: grant_type=client_credentials é um valor definido na especificação, e client_id e client_secret são strings arbitrárias que identificam o cliente. Não há nenhum valor fora do permitido.
NÃO CAIA NESSA!
A banca explora a confusão entre os fluxos do OAuth 2.0. No fluxo authorization code, a requisição ao endpoint de token exige grant_type=authorization_code, code, redirect_uri e client_id/client_secret. Já no fluxo client credentials, apenas grant_type, client_id e client_secret são obrigatórios. O candidato que memoriza o fluxo authorization code tende a marcar a alternativa A, achando que faltam parâmetros — mas aqui o fluxo é outro. Identificar o grant_type é o primeiro passo para resolver a questão.
PEGA ESSA DICA!
Para questões de OAuth 2.0, identifique primeiro o grant_type — ele define quais parâmetros são obrigatórios. Decore os quatro fluxos principais: authorization code (com code e redirect_uri), implicit (sem client_secret), client credentials (apenas credenciais do cliente) e resource owner password credentials (com username e password).