Depurador OAuth

Proof Key for Code Exchange (PKCE, RFC 7636) foi originalmente projetado para apps móveis e nativos que não conseguem armazenar um client secret com segurança. Funciona fazendo o cliente gerar um code_verifier aleatório, derivar dele um code_challenge (SHA-256 + base64url) e enviar o challenge junto com a requisição de autorização. Ao trocar o código de autorização por tokens, o cliente envia o code_verifier original. O servidor de autorização verifica se ele corresponde ao challenge anterior — provando que a requisição de token veio do mesmo cliente que iniciou o fluxo.

Mesmo para clientes confidenciais (aplicações server-side com um client secret), o PKCE agora é recomendado pelo OAuth 2.1 como defesa contra ataques de interceptação de código de autorização.

O fluxo implícito (response_type=token) foi projetado como um atalho para single-page apps, retornando o access token diretamente no fragmento da URL. Isso cria problemas sérios: tokens em URLs aparecem no histórico do navegador, logs de servidor e headers de referrer, e o fluxo é vulnerável a ataques de injeção de token. O OAuth 2.0 Security Best Current Practice (RFC 9700) e o OAuth 2.1 removem explicitamente o fluxo implícito em favor do Authorization Code + PKCE, que SPAs podem usar com segurança sem um client secret.

• PKCE obrigatório para todos os fluxos Authorization Code, incluindo clientes confidenciais.
• Fluxo Implicit removido — use Authorization Code + PKCE em vez disso.
• Resource Owner Password Credentials (ROPC) removido — o grant type password está obsoleto.
• Rotação de refresh token obrigatória para clientes públicos — um novo refresh token deve ser emitido a cada uso.
• Correspondência exata de redirect URI obrigatória — sem correspondência por padrão ou wildcards.

1. Gere o par PKCE: crie um code_verifier aleatório e calcule code_challenge = BASE64URL(SHA256(code_verifier)).
2. Redirecione para o endpoint de autorização: inclua response_type=code, client_id, redirect_uri, scope, state, code_challenge e code_challenge_method=S256.
3. O usuário se autentica no servidor de autorização e concede o consentimento.
4. Receba o código de autorização no seu redirect_uri junto com o state ecoado — verifique se o state corresponde ao que você enviou.
5. Troque o código por tokens: faça um POST para o endpoint de token com grant_type=authorization_code, code, redirect_uri, client_id e code_verifier.
6. Receba o access token (e, opcionalmente, id_token e refresh_token) e use-os para chamar APIs.