OAuth para redes sociais: como funciona
Uma explicação direta de como o fluxo OAuth funciona ao conectar uma conta de rede social a um produto de terceiros.
Por André LugQuase toda rede social usa alguma variação do mesmo protocolo para deixar um produto de terceiros publicar ou ler dados em nome de um usuário: o OAuth. Ele existe para resolver um problema específico — autorizar uma aplicação sem que o usuário entregue a senha da própria conta para ela.
O problema que o OAuth resolve
Antes do OAuth virar padrão, a alternativa era o próprio usuário digitar login e senha da rede social dentro do produto de terceiros — o que dá a esse produto acesso irrestrito e permanente à conta, sem jeito de revogar só aquele acesso sem trocar a senha inteira. O OAuth separa autenticação (provar quem o usuário é) de autorização (conceder um conjunto específico de permissões a uma aplicação específica, por um tempo determinado).
O fluxo de authorization code
A variante mais comum para aplicações com backend é o fluxo de authorization code: (1) a aplicação redireciona o usuário para uma página da própria rede social; (2) o usuário revisa o que está sendo pedido e autoriza; (3) a rede social redireciona de volta para a aplicação com um código de curta duração; (4) o backend da aplicação troca esse código por um token de acesso, numa chamada servidor-a-servidor que inclui um segredo que nunca é exposto ao navegador.
O ponto central é esse último passo: o código que aparece na URL de retorno não serve para nada sozinho — só o backend, de posse do segredo do app, consegue transformá-lo no token de acesso de verdade.
Escopos: autorização granular
Cada rede social define os seus próprios escopos (ou scopes) — permissões nomeadas como "publicar conteúdo", "ler métricas" ou "gerenciar comentários". A tela de autorização mostra exatamente quais escopos estão sendo pedidos, e o token emitido no fim do fluxo só serve para aquilo que foi concedido. Pedir mais escopo do que a integração realmente usa é o motivo mais comum de reprovação em processos de revisão de app como o App Review da Meta.
O token nem sempre é permanente
Cada provedor trata a validade do token de um jeito. Alguns emitem um par de token de acesso (curta duração) e token de renovação (refresh token), no espírito clássico da especificação OAuth 2.0. O Instagram, por exemplo, funciona diferente: o token de longa duração precisa ser trocado por um novo periodicamente, dentro de uma janela específica — o guia dedicado sobre isso está linkado abaixo. A regra prática vale para qualquer rede social: nunca assuma que uma conexão autorizada hoje continua válida para sempre sem monitorar o estado dela.
Como o PostGate simplifica isso
Em vez de implementar esse fluxo — redirecionamento, callback, troca de código, armazenamento seguro do token, renovação — para cada rede social separadamente, o PostGate expõe uma única chamada que cria uma URL de conexão hospedada. Você redireciona o cliente para ela, o PostGate conduz o OAuth (ou, para provedores baseados em credencial como Bluesky, Telegram e Mastodon, coleta o que for necessário diretamente na página hospedada) e devolve o cliente ao seu produto com o resultado.
curl -X POST https://postgate.studio/api/profiles/connect \
-H "Authorization: Bearer $POSTGATE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"platform": "instagram",
"profile_group_id": "grp_acme123",
"return_url": "https://app.example.com/settings/social"
}'
