Corrigir login OAuth quebrado em apps gerados por IA (produção)

O que realmente quebra quando o OAuth falha em produção

Falhas de OAuth parecem confusas porque seu código frequentemente parece correto. O provedor faz o que você pediu, mas uma pequena incompatibilidade entre local e produção faz o handshake falhar.

"Funciona localmente, mas falha em produção" normalmente se apresenta assim: você clica no Google ou GitHub, retorna para sua app e dá de cara com uma página em branco, um 401/403 ou um loop infinito de redirecionamento de volta ao botão de login. Às vezes o provedor mostra um erro claro (frequentemente sobre uma URL de redirecionamento). Outras vezes parece bem-sucedido, mas a app imediatamente esquece quem você é após o callback.

OAuth é exigente porque depende de URLs exatas e regras do navegador. O provedor compara seu redirect URI com o que você registrou. Sua app precisa ler o callback, validar o estado do login e setar um cookie de sessão que o navegador realmente enviará na próxima requisição. Pequenas diferenças como http vs https, www vs sem www ou uma flag de cookie podem ser a diferença entre “logado” e “quem é você?”

Sintomas comuns em produção:

• O provedor reclama de incompatibilidade no redirect URI
• O callback chega na sua app e então redireciona em círculos
• O login funciona uma vez, depois os usuários são deslogados ao atualizar
• Apenas alguns usuários falham (frequentemente Safari, iOS ou modo anônimo)
• Erros aparecem apenas atrás de um proxy ou no domínio real

Apps gerados por IA muitas vezes conectam auth de forma frágil: URLs de callback hard-coded, checagens de state faltando e configurações de cookie que passam localmente mas falham sob HTTPS real, domínios reais e defaults de privacidade de navegadores modernos.

Mapeie seu fluxo de login antes de mudar qualquer coisa

A maneira mais rápida de perder tempo é começar a mexer em configurações aleatórias sem um mapa claro. OAuth é uma cadeia. Uma suposição errada sobre qual URL é usada, onde a sessão vive ou onde o HTTPS é terminado pode quebrar todo o fluxo.

Anote o fluxo de produção exato (não o que você supõe do local). Muitos apps gerados por IA trocam URLs base com base em variáveis de ambiente, e alguns têm múltiplas rotas de callback (Google vs GitHub, web vs mobile).

Capture estes detalhes para comparar local vs staging vs produção:

• Origem do frontend (o que o navegador carrega) e origem da API (para onde as requisições vão)
• A URL de callback que sua app recebe depois que o provedor redireciona de volta
• O redirect URI registrado no provedor OAuth (string exata)
• Onde a sessão é armazenada (cookie, token em localStorage ou sessão no servidor)
• Sua infraestrutura de edge (proxy reverso/CDN) e onde o HTTPS vira HTTP

Cheque a realidade: se seu proxy termina o HTTPS, seu servidor de app pode ver requisições como http a menos que os headers encaminhados estejam corretos. Isso pode mudar URLs de callback geradas e flags de segurança dos cookies.

Exemplo: local funciona porque tudo é http://localhost em um domínio. Em produção, o frontend está em app.example.com, a API em api.example.com e o callback cai no host errado. O provedor redireciona com sucesso, mas seu cookie de sessão é escrito para o domínio da API e nunca alcança o frontend. Resultado: um loop de “deslogado”.

Incompatibilidades de Redirect URI: a maneira mais rápida de quebrar login social

Se quer uma vitória rápida, comece pelo redirect URI. Um caractere fora e o provedor bloqueará o callback.

A maioria dos provedores exige uma correspondência exata, incluindo:

• Esquema (http vs https)
• Domínio (www vs sem www, subdomínios)
• Path (incluindo barra final)
• Parâmetros de query (presentes, ausentes ou com ordem diferente)
• Porta (comum no dev local)

Problemas em produção frequentemente vêm da mistura de ambientes. Você testou com um domínio de staging, depois lançou com um domínio customizado, mas o provedor ainda só permite o callback do staging. Outro caso comum é uma ferramenta que gera múltiplas URLs de deploy (builds de preview, URLs temporários) e a app acidentalmente constrói o callback usando a errada.

Proxies podem piorar isso. Se sua app acha que está rodando em http, pode gerar um redirect URI http enquanto o site real é https. Em produção, isso aparece como um erro do provedor tipo “redirect_uri mismatch” ou uma página em branco após o login.

Exemplo simples: local usa http://localhost:3000/auth/callback, mas em produção deveria ser https://app.yourdomain.com/auth/callback (sem barra final). Se seu código produz https://app.yourdomain.com/auth/callback/, alguns provedores tratam isso como URL diferente e rejeitam.

Mau tratamento do callback e loops de redirecionamento

No fim do OAuth, o provedor envia o usuário de volta para sua app com a prova de que ele entrou. Se sua rota de callback for tratada como uma rota de página normal, pequenos erros podem se transformar em loops ou falhas “funciona localmente, falha em produção”.

O que a rota de callback deveria fazer

Um endpoint de callback deve ser curto e sem firulas. Se ele tenta renderizar UI, buscar dados do usuário primeiro ou passar pelo roteador normal com guards de auth, é fácil criar um loop.

Um handler de callback saudável faz isto:

• Lê a resposta do provedor (code, state e quaisquer campos error).
• Troca o code por tokens (server-side) e valida a resposta.
• Cria ou retoma uma sessão (seta os cookies certos) e armazena a identidade do usuário.
• Redireciona para uma página segura de “você está logado”.

Um bug comum em código gerado por IA é carregar a app completa no callback. O guard de auth da app vê “ainda não está logado” e imediatamente redireciona de volta ao provedor, criando um loop.

Trate erros do provedor sem travar

Provedores costumam retornar erros como access_denied (usuário cancelou) ou invalid_grant (code expirado ou já usado). Se seu código assume que code está sempre presente, você terá um 500, o frontend tentará de novo e o loop continua.

Mantenha o tratamento de erro simples:

• Se existir error, mostre uma mensagem amigável e ofereça um botão “Tentar novamente”.
• Se a troca de token falhar, registre um erro sanitizado e pare o fluxo.
• Não reutilize o mesmo auth code em uma nova tentativa. Inicie um login novo.

Também observe redirecionamentos pós-login. Muitas apps aceitam um parâmetro returnTo e redirecionam cegamente para ele. Isso pode causar caminhos quebrados (redirecionando de volta para /auth/callback) e risco de open-redirect. Permita apenas paths do mesmo site, padronize para uma página conhecida e remova anything suspeito.

Validação de state ausente e por que falha de forma intermitente

O valor state é uma tag de segurança que sua app cria antes de enviar alguém ao Google, GitHub ou outro provedor. Quando o provedor redireciona de volta, sua app deve verificar que o state retornado bate com o que foi emitido. Isso bloqueia ataques CSRF e confirma que o callback pertence à mesma sessão do navegador.

Quando state falta, é armazenado incorretamente ou não é validado, o comportamento costuma ser aleatório:

• Erros de “Invalid state” ou “CSRF detected” que os usuários não conseguem reproduzir
• Login funciona uma vez, depois falha na tentativa seguinte
• Usuários entram e são imediatamente desconectados após o callback
• Relatos do tipo “funciona no meu laptop, mas não em produção”

Por que se torna intermitente em produção: o state precisa sobreviver ao tempo entre o redirect inicial e o callback. Apps normalmente o armazenam na sessão do servidor (memória, Redis, banco) ou em um cookie de curta duração.

Se estiver em memória do servidor, produção quebra assim que você tem mais de uma instância. A requisição inicial pode atingir o servidor A, enquanto o callback atinge o B. O servidor B nunca viu aquele state.

Se estiver em cookie, as configurações de produção podem silenciosamente descartá-lo: Secure ausente atrás de HTTPS, domínio de cookie errado ou SameSite bloqueando no redirecionamento cross-site.

Também verifique PKCE. Para muitos provedores, clientes públicos (SPAs, mobile e algumas setups “sem backend”) devem usar PKCE: a app cria um code_verifier, o transforma em code_challenge e depois prova isso durante a troca de token. Se PKCE estiver faltando ou desalinhado, falhas podem aparecer apenas em certos dispositivos ou navegadores.

Problemas com cookies: SameSite, Secure, domain e path

Muitas falhas de OAuth são, na verdade, falhas de cookie. Sua app seta um cookie de sessão (ou um cookie temporário para o fluxo OAuth), mas o navegador não o envia de volta no callback. O lado do provedor está bem, mas sua app não consegue reconectar o usuário a uma sessão.

SameSite: por que callbacks se comportam diferente

Fluxos de OAuth pulam entre sites (sua app -> provedor -> sua app).

Com SameSite=Lax, cookies são enviados em muitas navegações top-level, mas edge cases aparecem com callbacks via POST, iframes ou visualizações de navegador customizadas. Se seu fluxo realmente precisa de cookies num callback cross-site, frequentemente você precisará de SameSite=None.

Se você definir SameSite=None, também precisa definir Secure, ou navegadores modernos ignoram o cookie.

Secure, domain e path: pequenas configurações, grande impacto

A produção roda em HTTPS e normalmente em domínios reais em vez de localhost. Verifique isto:

• Secure está habilitado no HTTPS, e não exigido por engano no HTTP local.
• Domain do cookie corresponde ao que o navegador vê (preste atenção em app.example.com vs example.com).
• Path do cookie não é excessivamente restrito (por exemplo /api quando seu callback atinge /auth/callback).
• Cookies não estão sendo sobrescritos no redirecionamento com configurações diferentes.
• O callback não é servido de um subdomínio diferente daquele onde o cookie foi setado.

Erros de CORS são barulhentos. Erros de cookie são silenciosos. Um bom sinal: se a chamada de rede retorna sucesso (200/302) mas o usuário ainda aparece desconectado, geralmente é cookie e não CORS.

Por fim, navegadores embutidos (webviews) e novas restrições a cookies de terceiros podem quebrar login social de formas que você não consegue reproduzir no desktop Chrome. Teste no dispositivo e ambiente reais dos usuários.

Erros de configuração só em produção para checar

Frequentemente o bug não está no código. Está na configuração de produção. Local funciona porque o ambiente é permissivo; produção é mais estrito.

Comece pelas variáveis de ambiente que controlam OAuth. Um valor errado pode causar uma página de login limpa seguida por um vago “algo deu errado” depois que o provedor redireciona de volta.

As incompatibilidades de configuração mais comuns

• Client ID e client secret pertencem ao app errado (credenciais de dev usadas em prod, ou vice-versa).
• Callback URL ou allowed redirect URLs não correspondem exatamente ao esquema, domínio e path de produção.
• Base URL da API aponta para localhost ou staging, então o callback troca um código contra o servidor errado.
• Configurações de cookie e sessão diferem em prod (Secure, domain, path), então a sessão não pode ser lida durante o callback.
• Um segredo rotacionado foi atualizado em um lugar mas não em outro (config do host vs console do provedor).

Se você herdou um projeto gerado por IA, também cheque por “fixes rápidos” onde segredos foram colados no frontend ou logados no console. Isso pode fazer um teste passar uma vez, mas cria um problema de segurança real e quebra novamente conforme os builds mudam.

Raro, mas real: clock skew

Trocas OAuth podem falhar se o horário do servidor estiver errado. É incomum, mas se tokens parecem expirados imediatamente, cheque sincronização de tempo do host e imagens de container.

Passo a passo: diagnostique um login OAuth quebrado de ponta a ponta

O caminho mais rápido é tornar a falha reproduzível e visível. Trate como um bug de checkout: um caminho, um navegador, um “este é o primeiro passo ruim.”

Use uma conta de teste no provedor e um perfil de navegador limpo (sem extensões, sem gerenciadores de senha). Se o bug “só acontece às vezes”, reduza variáveis.

Um fluxo simples que encontra causas rapidamente:

1. Reproduza uma vez e pare. Não tente 10 vezes e apague a trilha original.
2. Capture a cadeia completa de redirecionamento e copie a URL que falhou (incluindo query string).
3. Compare os redirect URIs permitidos do provedor com a URL de callback implantada que você capturou.
4. Inspecione cookies logo antes de ir ao provedor e logo após retornar. Confirme Domain, Path, Secure e SameSite.
5. Verifique que state e PKCE sejam criados, armazenados e validados. Confirme que o state enviado é o mesmo verificado no retorno.

Se os passos 1–5 parecerem corretos, foque na troca de tokens no servidor. Seu backend deve receber o code, trocar por tokens e lidar com erros sem loops. Logue a resposta de erro do provedor de forma sanitizada e retorne uma página de falha clara em vez de ficar pulando para /login para sempre.

Codebases gerados por IA frequentemente contêm lógica de retry “útil” ou rotas de callback duplicadas que tornam o comportamento em produção imprevisível.

Armadilhas comuns que pioram bugs de OAuth

Sob pressão, é fácil remediar sintomas e tornar o problema real mais difícil de diagnosticar.

Um erro comum é registrar um monte de redirect URIs “só para fazer funcionar”. Você acaba com quasi-duplicatas entre staging, produção e URLs de preview, e ninguém sabe qual a app realmente usa. Um deploy futuro troca domínios e o login quebra de novo.

Outra armadilha é desabilitar a validação de state para parar erros de “state mismatch”. Esse erro é normalmente um sinal real (problemas de cookie, múltiplas abas, roteamento multi-instância, callback quebrado). Desligar state remove uma verificação importante e aumenta risco.

Armazenamento de token é outro tiro no pé. Muitas apps geradas por IA colocam access tokens no localStorage porque é fácil. Se algum XSS passar, tokens são fáceis de roubar. Prefira sessões server-side ou cookies httpOnly quando possível.

Padrões que frequentemente causam falhas só em produção incluem domínios de cookie mal configurados, mistura de rotas SPA e rotas de API fazendo o callback atingir o handler errado, mascaramento de loops com redirecionamentos client-side extras e copiar código do provedor sem tratar parâmetros específicos do provedor.

Exemplo: sua rota de callback existe na SPA, mas o provedor manda usuários para um caminho de API. Localmente funciona por causa de rewrites dev; em produção o roteamento da plataforma é mais estrito.

Checklist rápido antes de aplicar a correção

Teste o login do jeito que usuários reais vão usá-lo: um navegador limpo, domínio HTTPS real e as configurações reais do provedor.

Checklist:

• Redirect URI é exatamente igual: mesmo esquema (https), host, path e barra final como salvo nas configurações do provedor.
• Callback termina claramente (sem loops): ou seta a sessão e redireciona uma vez, ou mostra uma página de erro clara.
• State é por tentativa e validado: gere um state novo a cada tentativa, armazene-o em segurança e verifique no retorno.
• Cookies sobrevivem ao callback: confirme que os cookies existem após o redirecionamento. Em HTTPS, eles devem ser Secure, e SameSite precisa corresponder ao fluxo (Some flows require SameSite=None+Secure`). Verifique também domain e path.
• Configuração de produção está real, não vazia: client ID/secret, callback URL, base URL da app e allowed origins batem com o domínio implantado.

Faça um teste em um perfil limpo, depois em mobile. Se só funciona quando você já entrou uma vez, provavelmente ainda há um problema com cookie ou state.

Um exemplo realista: local funciona, produção falha

Um fundador lança uma app gerada por IA que autentica bem no localhost. Assim que migram para o domínio real, o login do Google falha com um erro claro: redirect_uri_mismatch.

Eles atualizam as configurações do provedor. O erro some, mas agora a app fica rebatendo entre o provedor e o site em um loop. Às vezes cai na homepage ainda desconectada.

Duas pequenas diferenças em produção geralmente são suficientes para causar isso:

Primeiro, o redirect URI está quase certo, mas não exato. Por exemplo, a app envia https://app.example.com/auth/callback/ (barra final), enquanto o provedor permite apenas https://app.example.com/auth/callback (sem barra).

Segundo, o cookie de sessão que armazena o estado de login não é enviado no callback. Em produção, isso costuma acontecer quando SameSite não corresponde ao fluxo, ou quando Secure está faltando no HTTPS.

Um caminho prático de resolução:

• Faça o URI da app e do provedor baterem exatamente (esquema, host, path, barra final).
• Configure cookies corretamente para produção (Secure, SameSite apropriado, domain e path corretos).
• Confirme que a app persiste e valida state através do redirecionamento.

Para confirmar, teste em uma janela anônima, depois em uma normal e depois após reiniciar o navegador. Tente ao menos dois navegadores. O resultado esperado é chato: um redirecionamento para fora, um redirecionamento de volta e você permanece logado.

Próximos passos se seu auth gerado por IA ainda for instável

Se as checagens usuais não resolverem, pare de mudar configurações às cegas. A maioria dos bugs de auth “quase funcionando” vem de logs faltantes, propriedade de URLs confusa ou caminhos de código emaranhados que se comportam diferente sob domínios reais e HTTPS.

Anote as URLs de produção exatas envolvidas: sua base URL, a URL de callback do provedor e quaisquer páginas intermediárias de redirecionamento. Trave essas no provedor. Pequenas diferenças (www vs sem www, barra final, http vs https) podem gerar falhas que parecem intermitentes porque usuários entram por pontos de entrada diferentes.

Adicione logging mínimo ao redor do callback para ver o que falhou sem vazar segredos. Registre timestamp, nome do provedor, status HTTP e um código de erro interno seguro. Não imprima tokens, códigos de auth, cookies de sessão ou query strings completas.

Se o código foi gerado por IA, a instabilidade frequentemente vem de handlers de auth duplicados, abordagens mistas de sessão (cookies mais localStorage) ou redirecionamentos que escondem erros reais. Uma refatoração focada costuma ser mais rápida que remendos:

• Um endpoint de callback por provedor
• Valide state (e nonce quando aplicável) em um único lugar, sempre
• Restrinja redirecionamentos pós-login a uma allowlist curta
• Centralize configurações de cookie (Secure, SameSite, domain, path)
• Forneça uma página de erro clara para logins falhos

Se você herdou um protótipo bagunçado e o login em produção continua quebrando, FixMyMess (fixmymess.ai) foi feito para essa situação exata. Nós diagnosticamos codebases geradas por IA, reparamos lógica de auth, endurecemos cookies e checagens de segurança e preparamos a app para deploys de produção.