❌ ERRADO.

Por quê?

Porque PKCE não serve para garantir a confidencialidade de toda a comunicação.

O objetivo principal do PKCE é proteger o Authorization Code contra ataques de interceptação.

toda prova do cespe aparece um termo novo

Alguem ja ouviu falar de "pkce" antes dessa prova

GABARITO: ❌ ERRADO

⚠️ O PEGA DA BANCA:

• A banca atribuiu ao PKCE a função de garantir a confidencialidade dos dados transmitidos e impedir a interceptação do conteúdo das comunicações no acesso a recursos; essa proteção de trânsito cabe ao TLS/HTTPS, enquanto o PKCE atua apenas na troca segura do código de autorização.

✅ FUNDAMENTAÇÃO:

• O PKCE (Proof Key for Code Exchange) mitiga o ataque de interceptação do código de autorização (Authorization Code Injection) em clientes públicos. Já o sigilo/confidencialidade dos dados em trânsito entre cliente e Resource Server é garantido exclusivamente pela camada de transporte criptografada (TLS/HTTPS).

⚡ BIZU RÁPIDO:

• PKCE = Protege o auth code contra roubo/injeção local | TLS (HTTPS) = Garante a confidencialidade em trânsito (anti-interceptação).

➡️ Bons estudos!

➡️ Vamos juntos rumo à posse!

➡️ INSTAGRAM: @informaticaconcursos_

Função do PKCE: Proteger o fluxo contra ataques de interceptação do código de autorização (Authorization Code Interception Attack), mitigando riscos em aplicativos públicos (como apps móveis e Single Page Applications) onde o Client Secret não pode ser armazenado com segurança. Ele garante que quem troca o código pelo Access Token é a mesma instância da aplicação que iniciou a requisição.

O framework OAuth 2.0 não criptografa o tráfego de dados (o conteúdo da comunicação) entre o cliente e o servidor de recursos. Na verdade, a RFC oficial do OAuth 2.0 delega totalmente essa função e exige o uso obrigatório de TLS (HTTPS) justamente porque o OAuth, por si só, não garante a confidencialidade do canal contra interceptação (sniffing).

O papel do PKCE (Proof Key for Code Exchange): O fluxo com PKCE não foi concebido para proteger o dado final. Ele foi criado para proteger exclusivamente a etapa inicial de troca do código de autorização.

• O problema real: Em aplicativos de celular ou Single Page Applications (SPA), que são clientes "públicos" e não conseguem esconder uma senha fixa (Client Secret), um app malicioso instalado no mesmo dispositivo poderia interceptar o código de autorização durante o redirecionamento do navegador e trocá-lo pelo Access Token.
• A solução PKCE: Ele cria um segredo dinâmico e temporário (Code Challenge e Code Verifier) para provar ao servidor que o aplicativo que está solicitando o token final é exatamente o mesmo que iniciou o pedido de login lá no começo.

Quem impede o sequestro do código de autorização por um aplicativo malicioso no dispositivo? PKCE.

Quem garante a confidencialidade e impede a interceptação do conteúdo trafegado na rede? TLS/HTTPS.

Gabarito: Errado!