Pergunta de entrevista para Desenvolvedor Full Stack

Me explique o fluxo OAuth de authorization code com PKCE.

O que o entrevistador está avaliando, como estruturar sua resposta e um exemplo falado que você pode adaptar.

Resposta rápida

O cliente gera um verifier aleatório, gera um hash dele para virar o code challenge, e redireciona o usuário ao servidor de autorização com esse challenge. O usuário se autentica, é redirecionado de volta com um code de uso único, e o cliente troca esse code mais o verifier original por tokens. Como a troca exige o verifier, um code interceptado é inútil. O OAuth 2.1 exige PKCE para todo cliente, público ou confidencial.

Por que os entrevistadores perguntam isso

Quase todo produto faz login social ou uma integração de terceiro, então o entrevistador quer saber se você já implementou um ou só clicou por dentro de uma biblioteca. Ele está escutando o redirecionamento, a troca do code acontecendo de servidor para servidor, e por que o PKCE existe. Um sinal extra vem de separar autorização OAuth de autenticação OIDC, que é a distinção que a maioria dos candidatos borra.

Como estruturar sua resposta

  • Trace o fluxo em ordem, do verifier até a troca de token.
  • Explique que ataque o PKCE evita.
  • Distinga o ID token do access token.
  • Diga onde cada token termina do seu lado.

Exemplo de resposta

Exemplo falado, em primeira pessoa

O cliente começa gerando um verifier de alta entropia e aplicando SHA-256 nele para formar o code challenge. Ele manda o usuário para o servidor de autorização com o client id, a redirect URI, os escopos, um valor de state e aquele challenge. O usuário faz login e dá consentimento, e o servidor de autorização redireciona de volta com um code de vida curta. O cliente então faz um POST com aquele code e o verifier cru no endpoint de token, o servidor gera o hash do verifier e confere se bate com o challenge que ele guardou, e só então emite os tokens. É esse o ponto inteiro do PKCE: um code roubado de um redirecionamento, de um log ou de um app malicioso no dispositivo não pode ser resgatado sem o verifier, que nunca saiu do cliente. Eu ainda valido o state separadamente, porque isso cobre CSRF no callback e não interceptação de code. Se eu estou fazendo login em vez de acesso a API, o que me interessa é o ID token do OIDC e eu valido a assinatura, o emissor, a audiência e o nonce dele antes de confiar em qualquer claim.

Vai encarar essa entrevista em breve? O GhostPilot escuta a sua chamada ao vivo, identifica a pergunta no instante em que ela é feita e coloca uma resposta estruturada na sua tela em tempo real. Teste na sua próxima entrevista simulada ou pegue um Session Pass de $29, sem assinatura, para a hora da verdade.

Veja como funciona

Perguntas de acompanhamento que você pode esperar

  • Do que o parâmetro state protege que o PKCE não protege?
  • Qual é a diferença entre um ID token e um access token?
  • Onde você guardaria o refresh token para um cliente rodando no navegador?

Mais perguntas para Desenvolvedor Full Stack

Seu entrevistador vai fazer a própria versão desta. Cole a descrição real da vaga no Question Predictor gratuito e receba as 20 perguntas que essa vaga tem mais chance de fazer, com o que cada uma está de fato sondando.

Prever minhas perguntas

Ensaie as perguntas difíceis antes que elas apareçam

Pratique com um copiloto ao vivo e depois entre pronto. Um Session Pass de $29 te leva até o fim da entrevista, sem assinatura e sem amarras.

Instalar o GhostPilot