OAuth: como funciona o 'Entrar com Google'
Seu aplicativo nunca vê a senha do Google do usuário — e é justamente esse design que torna login social mais seguro do que parece à primeira vista.
Todo botão "Entrar com Google" (ou GitHub, ou qualquer outro provedor) esconde um protocolo chamado OAuth. A confusão mais comum é achar que a sua aplicação recebe a senha do Google do usuário de alguma forma — ela nunca recebe. O design inteiro do protocolo existe justamente pra impedir isso.
O fluxo, em alto nível: authorization code
Clique em “Reproduzir fluxo” para ver a requisição passo a passo.
O passo 3 é o coração do design: a autenticação de verdade acontece inteiramente dentro do domínio do Google, numa página que o Google controla. Sua aplicação só recebe, no passo 4, um código — não uma senha, não um token ainda utilizável diretamente pelo navegador.
Por que o código não é o token final
Se o Google devolvesse o token de acesso direto pro navegador logo no redirecionamento, ele ficaria exposto na URL — visível no histórico do navegador, em logs de proxy, em qualquer lugar que registre a URL acessada. Em vez disso, o Google devolve um código de uso único, de vida curta, que só serve pra uma coisa: ser trocado por um token de verdade — e essa troca acontece numa chamada direta servidor a servidor, autenticada com uma chave secreta que só o seu backend conhece (nunca exposta no navegador).
POST /oauth/token HTTP/1.1
Host: accounts.google.com
grant_type=authorization_code
&code=4/0AY0e-g7...
&client_id=SEU_CLIENT_ID
&client_secret=SEU_CLIENT_SECRET ← nunca sai do backend
&redirect_uri=https://seusite.com/callbackMesmo que alguém capture o código de autorização de alguma forma (ele aparece brevemente na URL de retorno), sem o client_secret — que fica só no servidor, nunca no navegador nem em código client-side — não é possível completar a troca por um token utilizável.
O que o seu backend faz com o token do Google
Depois da troca, o Google devolve informações básicas do usuário (nome, email, um identificador único) junto com o token. A partir daí, é o seu sistema quem decide como autenticar essa pessoa dentro da sua própria aplicação — tipicamente criando (ou reconhecendo) um usuário local vinculado a esse email/id do Google, e então emitindo sua própria sessão (cookie, lição 2) ou JWT (lição 5) pra ela, exatamente como faria num login tradicional. O token do Google raramente é usado direto pra autorizar chamadas dentro da sua própria API — ele serve só pra confirmar identidade nesse momento inicial.
Exercício
Um desenvolvedor implementa "Entrar com Google" de um jeito diferente: o token de acesso do Google é devolvido diretamente pro JavaScript do navegador (sem passar pelo backend), e o próprio frontend faz a troca do código pelo token, guardando o client_secret num arquivo JavaScript do bundle da aplicação. O que está errado nessa implementação?