OAuth: como funciona o login com Google por trás dos panos

Já expliquei aqui a diferença entre autenticação e autorização, e o botão "Entrar com Google" que aparece em praticamente todo sistema hoje é um exemplo prático dos dois conceitos trabalhando juntos, através de um protocolo chamado OAuth. Vale entender o que acontece de verdade entre o clique nesse botão e o usuário aparecer logado no seu sistema.

O problema que o OAuth resolve

Antes do OAuth virar padrão, alguns sites pediam literalmente o e-mail e a senha do Google do usuário, pra entrar na conta dele e confirmar quem era essa pessoa. Isso é um risco absurdo: a sua aplicação passaria a guardar a senha de um serviço que não é nem seu, e qualquer falha de segurança nesse meio expõe a conta inteira do usuário no Google, não só no seu sistema.

O OAuth existe justamente pra eliminar essa necessidade. Ele permite que um usuário autorize sua aplicação a confirmar a identidade dele (ou acessar algum dado específico) sem nunca entregar a senha pra sua aplicação. A senha fica só entre o usuário e o provedor (Google, GitHub, o que for).

O fluxo passo a passo

O mais comum hoje é o chamado authorization code flow, e ele segue mais ou menos essa sequência:

1. Sua aplicação redireciona o usuário pro provedor. Quando o usuário clica em "Entrar com Google", ele não fica na sua página, é redirecionado pra uma URL do próprio Google, com alguns parâmetros informando quem está pedindo (client_id) e o que está sendo pedido (scope, tipo e-mail e nome básico).

https://accounts.google.com/o/oauth2/auth?
  client_id=SEU_CLIENT_ID&
  redirect_uri=https://seusite.com/callback&
  scope=email profile&
  response_type=code

2. O usuário autoriza direto no Google. A tela de login que aparece é do próprio Google, com o domínio do Google na barra de endereço. Sua aplicação nunca vê o que o usuário digita ali, essa parte acontece inteiramente do lado do provedor.

3. O Google redireciona de volta com um código. Depois de autorizado, o Google manda o usuário de volta pra redirect_uri que você configurou, com um código temporário na URL:

https://seusite.com/callback?code=abc123

Esse código não é a informação final, é só um comprovante de que a autorização aconteceu.

4. O backend troca o código por um token. Aqui é onde entra a parte que precisa acontecer no servidor, nunca no navegador: seu backend pega esse code e faz uma requisição direta pro Google, junto com o client_secret (uma chave que só existe no seu servidor, nunca exposta no frontend), trocando o código por um access token de verdade.

const resposta = await fetch("https://oauth2.googleapis.com/token", {
  method: "POST",
  body: new URLSearchParams({
    code,
    client_id: process.env.GOOGLE_CLIENT_ID,
    client_secret: process.env.GOOGLE_CLIENT_SECRET,
    redirect_uri: "https://seusite.com/callback",
    grant_type: "authorization_code",
  }),
});

5. Sua aplicação usa o token pra pegar o dado do usuário. Com o access token em mãos, o backend faz mais uma requisição, agora pra buscar as informações básicas do usuário (e-mail, nome), e com isso já consegue criar ou autenticar a conta correspondente no seu próprio sistema.

Por que o código intermediário existe

Uma pergunta comum é por que o Google não devolve o token direto no passo 3, sem esse código intermediário. O motivo é segurança: o passo 3 acontece na URL do navegador, que pode aparecer em histórico, em log de servidor, em extensão instalada. Um token de acesso ali seria uma informação sensível exposta num lugar visível demais. O código sozinho, sem o client_secret (que só existe no seu backend), não serve pra nada na mão de outra pessoa, então expor ele na URL não é um risco real.

Autenticação e autorização, juntas

Vale notar como os dois conceitos aparecem misturados aqui. O scope email profile é sobre autorização: o usuário está autorizando sua aplicação a ler essas informações específicas, nada além disso. O resultado final, o backend confirmando quem é essa pessoa a partir do e-mail retornado, é a parte de autenticação. O OAuth em si é um protocolo de autorização, mas usado desse jeito, com scope de identidade básica, ele vira também um mecanismo de login.

Fechando

O botão "Entrar com Google" parece simples de fora, mas por trás existe um fluxo desenhado especificamente pra que a senha do usuário nunca passe pela sua aplicação, o token nunca fique exposto onde não deveria, e cada etapa (autorização, troca de código, busca de dado) aconteça no lugar certo, navegador ou backend. Entender esse fluxo ajuda bastante o dia em que você precisar implementar isso do zero, ou simplesmente depurar por que um login social parou de funcionar.