Como resolvi o erro 400: redirect_uri_mismatch no Google oauth 2.0

Se você já precisou colocar login social com o Google em alguma aplicação web, há uma chance real de já ter dado de cara com esta mensagem na tela de autenticação:

Erro 400: redirect_uri_mismatch
Não é possível fazer login no app porque ele não obedece à política do OAuth 2.0 do Google.
Se você é o desenvolvedor do app, registre o URI de redirecionamento no Console do Google Cloud.
Detalhes da solicitação: redirect_uri=https://app.dominio.com.br flowName=GeneralOAuthFlow

Em um primeiro momento, a mensagem assusta quem está subindo um projeto para produção. O OAuth 2.0 do Google é intencionalmente rígido com esse parâmetro: o redirect_uri é a âncora de segurança que impede que um token de autorização seja desviado para um domínio malicioso.

Abaixo, detalho o que acontece por baixo dos panos e como diagnosticar e corrigir o problema no painel do Google Cloud (GCP).

O que acontece por baixo dos panos?#

Quando o usuário clica no botão "Entrar com Google", o navegador faz uma requisição para os servidores de autorização do Google (accounts.google.com/o/oauth2/v2/auth) enviando parâmetros essenciais:

• client_id: o identificador público da sua aplicação.
• response_type: geralmente code no fluxo padrão de autorização.
• scope: os dados solicitados (como e-mail e perfil básico).
• redirect_uri: a URL exata para onde o Google deve devolver o código de autorização após o aceite do usuário.

Assim que a requisição chega, o Google compara o valor do redirect_uri enviado com a lista de URIs de redirecionamento autorizados cadastrados nas credenciais do seu projeto no GCP.

Essa comparação é feita de forma estrita, caractere por caractere. Se houver uma única letra, barra ou protocolo diferente, o Google bloqueia o fluxo imediatamente com status 400 Bad Request antes mesmo de abrir a tela de escolha de contas.

As 4 causas mais comuns do erro#

Na prática, esse erro quase sempre é provocado por uma destas quatro situações:

1. Divergência de protocolo (http:// vs https://)#

Em ambiente local usa-se http://localhost, mas em produção tudo roda sob SSL (https://). Se a aplicação estiver atrás de um proxy reverso (Nginx, Traefik, Cloudflare) que não repassa os cabeçalhos X-Forwarded-Proto corretamente, a aplicação pode montar a URL de callback com http://, gerando conflito com o cadastro https:// do console.

2. A barra final na URL (trailing slash)#

Para o validador do Google, estas duas strings são completamente diferentes:

• https://app.dominio.com.br/callback
• https://app.dominio.com.br/callback/

Se o backend enviar a rota sem a barra e no GCP ela estiver com barra (ou o contrário), o casamento falha.

3. Subdomínio www vs domínio raiz#

https://www.dominio.com.br e https://dominio.com.br são origens distintas para o provedor OAuth. Se sua aplicação permite acesso por ambos sem redirecionamento 301 forçado, ambas as URLs precisam constar na lista de autorização.

4. Transição de ambiente (dev para produção)#

Durante o desenvolvimento local, cadastramos apenas http://localhost:3000/api/auth/callback/google. Ao publicar o projeto no domínio oficial, esquecer de adicionar a URL pública definitiva na credencial do GCP é a causa mais recorrente do problema.

Como diagnosticar no caso real#

O próprio Google entrega o valor exato que falhou nos detalhes da tela de erro:

Detalhes da solicitação: redirect_uri=https://app.dominio.com.br flowName=GeneralOAuthFlow

O endpoint que a minha aplicação estava requisitando como retorno era https://app.dominio.com.br. O motivo da recusa foi direto: essa URI exata não estava cadastrada na lista de permissões daquele client_id.

Passo a passo para corrigir no Google cloud console#

Para regularizar o acesso:

1. Acessar o Google Cloud Console:

Entre em console.cloud.google.com autenticado na conta proprietária do projeto.

1. Navegar até as credenciais:

No menu lateral esquerdo, vá em APIs e Serviços > Credenciais.

1. Editar o Client ID OAuth 2.0:

Na lista de IDs do cliente OAuth 2.0, clique sobre o nome da credencial que sua aplicação utiliza.

1. Adicionar a URI Autorizada:

Role até a seção URIs de redirecionamento autorizados (Authorized redirect URIs) e clique em + Adicionar URI. Insira a URL idêntica à informada nos detalhes do erro:

https://app.dominio.com.br

(Se seu framework esperar um caminho específico, como /api/auth/callback/google ou /auth/google/callback, adicione a rota completa).

1. Salvar as alterações:

Clique em Salvar na parte inferior da página.

O que conferir antes de colocar em produção#

Depois de salvar no Google Cloud, a propagação interna da alteração costuma levar entre alguns segundos e 5 minutos. Reinicie o fluxo de login no navegador: a tela de consentimento do Google passará a abrir normalmente.

A regra prática para evitar dores de cabeça com OAuth 2.0 é não confiar em aproximações de string. Sempre confira o valor literal impresso no campo redirect_uri da mensagem de erro e registre exatamente a mesma sequência de caracteres nas credenciais do console.

Veja também

Desenvolvimento Atualizando o Vite no Laravel: do inotify do kernel ao manifest.json

Desenvolvimento Como integrar o IndexNow: indexação instantânea para sites, SaaS e APIs

Desenvolvimento Bun, Node.js e PM2 em produção: quando usar, quando evitar e trade-offs arquiteturais

Este post está licenciado sob CC BY-NC.