Questão de Segurança da Informação — Autenticação — FGV 2026
Segurança da Informação›Autenticação
Código
fg133878
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Analista de Segurança da Informação
A analista Renata está implementando o fluxo Authorization Code Grant com Proof Key for Code Exchange (PKCE), do OAuth 2.0, em um aplicativo mobile, a fim de acessar uma API protegida. Conforme as especificações do OAuth 2.0 para esse fluxo, o servidor de autenticação deve efetuar certas validações na fase de troca do código de autorização pelo token de acesso. A passagem de parâmetros para o servidor de autenticação foi implementada pela analista de forma correta, ao longo de todo o fluxo.Cabe ao servidor de autorização verificar, na referida fase, se:
Ao code e o challenge recebidos são válidos e se o challenge foi derivado do respectivo verifier;
Bo code e o verifier recebidos são válidos e se o challenge foi derivado do respectivo verifier;
Co challenge e o verifier recebidos são válidos e se o challenge foi derivado do respectivo code;
Do code e o verifier recebidos são válidos e se o verifier foi derivado do respectivo challenge;
Eo challenge e o verifier recebidos são válidos e se o code foi derivado do respectivo challenge.
Revelar gabarito e comentário▾
GabaritoB — o code e o verifier recebidos são válidos e se o challenge foi derivado do respectivo verifier;
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 Authorization Code Grant com PKCE
Gabarito: letra B. No fluxo PKCE, o servidor de autorização, ao receber a solicitação de troca do código de autorização por token, deve: (1) validar o código de autorização; (2) validar o code_verifier enviado pelo cliente; (3) verificar que o code_challenge (já recebido na requisição de autorização) foi derivado a partir desse code_verifier. Essa verificação é feita aplicando a mesma transformação (ex.: SHA256) e comparando o resultado com o code_challenge armazenado. A alternativa B captura exatamente esses três pontos.
NÃO CAIA NESSA!
A banca explora a confusão entre os parâmetros enviados em cada etapa. Na troca do código pelo token, o cliente envia o code_verifier, não o code_challenge. O code_challenge só é enviado na requisição de autorização inicial. Muitos candidatos invertem esses papéis.
1Client gera verifier e challenge
2Auth request: envia challenge
3Auth response: devolve code
4Token request: envia code + verifier
5Server valida code, verifier e derivação
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Afirma que o servidor recebe e valida o challenge na fase de troca. Na verdade, o challenge já foi recebido na requisição de autorização; na troca, o cliente envia o verifier. Portanto, o servidor não recebe novamente o challenge.
Alternativa B — ✅ Correta ⟵ GABARITO
Exatamente como descrito: o servidor valida o código, o verifier e se o challenge foi derivado do verifier. É a descrição correta do que ocorre no token endpoint do fluxo PKCE.
Alternativa C — ❌ Incorreta
Afirma que o challenge é derivado do code. Em PKCE, o challenge é derivado do verifier, não do código de autorização. A relação é challenge = transform(verifier).
Alternativa D — ❌ Incorreta
Afirma que o verifier é derivado do challenge. A direção é oposta: o challenge é derivado do verifier. O verifier é gerado primeiro e o challenge é computado a partir dele.
Alternativa E — ❌ Incorreta
Afirma que o code é derivado do challenge. O código de autorização é gerado pelo servidor independentemente do PKCE; não há derivação criptográfica entre code e challenge.
PEGA ESSA DICA!
Monte o fluxo PKCE mentalmente: (1) Client gera verifier e challenge; (2) Authorization request → envia challenge + method; (3) Authorization response → code; (4) Token request → envia code + verifier; (5) Server recalcula challenge a partir do verifier e compara com o armazenado. Essa sequência resolve a questão.