A analista Renata está implementando o fluxo Authorization C...

Próximas questões
Com base no mesmo assunto
Q3874323
Segurança da Informação Autenticação ,
Ano: 2026 Banca: FGV Órgão: TJ-RJ Prova: FGV - 2026 - TJ-RJ - Analista Judiciário - Tecnologia da Informação - Analista de Segurança da Informação |
Q3874323 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: 
Alternativas

Gabarito comentado

Confira o gabarito comentado por um dos nossos professores

Gabarito: B

Fundamento decisivo: Na fase de troca do código por token, o ponto decisivo é que o servidor recebe o code e o code_verifier e valida essa correspondência; isso afasta as alternativas que falam em challenge como parâmetro recebido nessa etapa ou invertem a derivação.

Tema central: Validação do PKCE
Análise das alternativas
A
Errada
Está errada porque trata o challenge como parâmetro recebido nessa fase de troca. No token endpoint, o parâmetro recebido é o code_verifier; o code_challenge já foi enviado antes, na authorization request, e ficou associado ao code.
B
Certa
A alternativa B descreve o procedimento do token endpoint no fluxo Authorization Code com PKCE: o servidor valida o authorization code e o code_verifier recebidos e confere se o code_challenge previamente associado ao code foi derivado do verifier, conforme a RFC 7636, seção 4.6.
C
Errada
Está errada em dois pontos concretos: considera o challenge como elemento recebido nessa fase e afirma derivação do challenge a partir do code. No PKCE, o challenge é derivado do code_verifier, não do authorization code.
D
Errada
Está errada por inverter o sentido da derivação. Mesmo mencionando code e verifier como recebidos, afirma que o verifier foi derivado do challenge, mas no PKCE a relação correta é challenge derivado do verifier.
E
Errada
Está errada porque erra os elementos da fase e a relação técnica entre eles. O challenge não é o parâmetro recebido no token endpoint e o authorization code não é derivado do challenge no PKCE.
Pegadinha da questão
A questão explora duas confusões reais: trocar o parâmetro da authorization request pelo da token request e inverter o sentido da derivação entre verifier e challenge.
Dica para questões semelhantes
  • Separe mentalmente os parâmetros por fase: code_challenge na authorization request; code e code_verifier na token request.
  • Em PKCE, a verificação técnica é sempre recalcular o challenge a partir do verifier recebido e comparar com o challenge previamente associado ao code.
  • Se a alternativa disser que verifier vem do challenge ou que code vem do challenge, elimine, porque esse não é o encadeamento do protocolo.

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

Na fase de troca do código de autorização pelo token de acesso, o servidor de autorização deve realizar as seguintes validações: verificar se o código de autorização (`code`) e o `code_verifier` recebidos são válidos, e então confirmar se o `code_challenge` (armazenado previamente) foi corretamente derivado desse `code_verifier`.

Isso está em conformidade com a RFC 7636, que especifica que o servidor deve calcular o desafio a partir do verificador recebido e compará-lo com o desafio armazenado. Caso os valores coincidam, a troca prossegue; caso contrário, um erro `invalid_grant` é retornado.

Portanto, a alternativa que descreve corretamente essas verificações é:

**B) o code e o verifier recebidos são válidos e se o challenge foi derivado do respectivo verifier**

1-> Cria o code_verifier: Senha123@

3-> code_challenge embaralha

4 -> App envia o code_challenge pro servidor

5 -> Server devolve o authorization_code

6 -> App envia o code_verifier para o servidor para receber o token

7 -> Servidor faz hash do code_verifier

8 -> Compara se o hash de agora é igual ao code_challenge

9 -> Se for igual libera o token

A alternativa correta é a B: o code e o verifier recebidos são válidos e se o challenge foi derivado do respectivo verifier;. [1]

Explicação Detalhada:

No fluxo OAuth 2.0 com PKCE (Proof Key for Code Exchange), o processo ocorre em duas etapas principais de comunicação com o servidor de autorização: [1, 2]

  1. Solicitação de Autorização: O aplicativo cliente gera um segredo criptográfico aleatório chamado code_verifier e calcula um hash dele, chamado code_challenge. O aplicativo envia apenas o code_challenge ao servidor para obter o código de autorização (code).
  2. Solicitação de Token (Troca): Após receber o code, o cliente envia ao endpoint de token o code e o code_verifier (verifier) original. [1, 2]

Nesta fase de troca, o servidor de autorização realiza as seguintes checagens:

  • Verifica se o code e o verifier recebidos nesta requisição são válidos.
  • Aplica o método de transformação (como o algoritmo SHA-256) sobre o verifier recebido para certificar-se de que o challenge (enviado e salvo na primeira etapa) realmente foi derivado desse verifier. Isso garante que o aplicativo que está pedindo o token de acesso é exatamente o mesmo que iniciou o fluxo. [1, 3]

Clique para visualizar este comentário

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

Questões de assuntos semelhantes

Provas relacionadas