O que são OAuth 2.0 e Login Social?

OAuth 2.0 é um padrão de autorização que permite a um app acessar a conta de um usuário em outro serviço — o login social constrói a autenticação por cima. Os dois costumam ser explicados em separado, e é assim que a confusão sobrevive: a RFC 6749 define o encanamento (acesso delegado e com escopo, sem compartilhar senhas), o OpenID Connect adiciona a camada de identidade, e o botão de “Entrar com…” é o recurso de produto montado sobre os dois.

Principais pontos

O fluxo authorization code, passo a passo

A dança de redirects por trás de toda tela de consentimento — com os parâmetros que importam:

1  App → provedor    /authorize?client_id=…&redirect_uri=…&scope=profile
                     &state=af3G…            ← guarda anti-CSRF, conferida na volta
                     &code_challenge=hK9…    ← PKCE: hash de um segredo recém-criado

2  Usuário ↔ provedor   Faz login LÁ (a senha nunca toca o app) e consente

3  Provedor → app    redirect_uri?code=SplxlO…&state=af3G…   ← código de uso único

4  App → provedor    POST /token  { code, code_verifier }    ← prova do PKCE
   Provedor → app    { access_token, refresh_token, id_token }

5  App → API         Authorization: Bearer <access_token>

Como isso fica quando um backend embrulha o fluxo — tokens do provedor entram, sessão verificada sai:

// JavaScript / Node.js — Back4app JS SDK
// Social login: the provider's tokens become a user session
const user = await Parse.User.logInWith('apple', {
  authData: { id: appleUserId, token: identityToken },
});
// First login creates the user; later logins match — session token issued

// Account linking: attach a second provider to the same user
await user.linkWith('facebook', { authData: fbAuthData });

// Flutter / Dart — Back4app Flutter SDK
// Social login: the provider's tokens become a user session
final user = ParseUser.forQuery();
final response = await user.loginWith(
  'apple',
  apple(identityToken, appleUserId),
);
// First login creates the user; later logins match — session token issued

// Account linking: attach a second provider to the same user
await user.linkWith('facebook', facebook(token, fbUserId, expiresAt));

// iOS / Swift — Back4app Swift SDK
// Social login: the provider's tokens become a user session
let user = try await User.apple.login(
    user: appleUserId,
    identityToken: identityTokenData
)
// First login creates the user; later logins match — session token issued

// Account linking: attach a second provider to the same user
try await user.facebook.link(userId: fbUserId, accessToken: fbAccessToken)

// Android / Kotlin — Back4app Android SDK
// Social login: the provider's tokens become a user session
val authData = mapOf("id" to appleUserId, "token" to identityToken)
ParseUser.logInWithInBackground("apple", authData).continueWith { task ->
    val user = task.result
    // First login creates the user; later logins match — session token issued

    // Account linking: attach a second provider to the same user
    user.linkWithInBackground("facebook", fbAuthData)
}

Os quatro papéis

Grant types: qual fluxo, e o que o OAuth 2.1 mudou

O OAuth 2.1 é consolidação, não revolução: as remoções acima, mais redirect URIs de correspondência exata e a proibição de bearer tokens em query strings — as lições de segurança acumuladas de uma década dobradas de volta em um só documento. Os explicadores por aí em geral não acompanharam; vários ainda ensinam o fluxo implicit sem qualquer ressalva.

OAuth vs. OpenID Connect: autorização vs. autenticação

A frase que todo mundo repete — “OAuth não é autenticação” — merece seu mecanismo, porque é o mecanismo que torna o login ingênuo explorável:

“Login com um access token puro” falha porque access tokens são evidência transferível de permissão, não de presença: um app malicioso que obteve um token para os próprios fins poderia reapresentá-lo em outro lugar para se passar pelo usuário. O OpenID Connect existe precisamente para fechar essa brecha — os mesmos fluxos, mais uma asserção de identidade criptograficamente vinculada ao seu app.

Login social: o botão em cima do encanamento

Login social é o OIDC embalado como UX: o provedor autentica, seu app recebe claims verificados e cria ou encontra uma conta — nenhuma senha armazenada, nenhum fluxo de redefinição para manter, a MFA do provedor herdada de graça. Os trade-offs de produto merecem números honestos. As alegações de 20–50% de aumento no cadastro são folclore de fornecedor; testes controlados mediram algo mais perto de 3% — ainda que cerca de um terço dos logins de consumo hoje chegue pela via social, sinal claro de que os usuários querem a opção. As práticas que de fato movem a conversão: ofereça dois ou três provedores que a sua audiência usa (o “grid de largada” de botões comprovadamente atrapalha), mantenha sempre a alternativa por e-mail, e saiba que redirects de OAuth quebram dentro de WebViews embutidas — uma causa real de falha de cadastro no mobile. Dois fatos específicos de provedor pesam o bastante para serem nomeados: o Sign in with Apple emite endereços de relay privado (…@privaterelay.appleid.com), então vinculação por e-mail e listas de e-mail precisam esperar aliases opacos — e as regras da App Store exigem que apps que oferecem login de terceiros ofereçam também o da Apple.

Vinculação de contas e a armadilha do e-mail

A mesma pessoa vai chegar por dois provedores, e os dois vão informar [email protected]. A regra que evita a vulnerabilidade clássica: a identidade se ancora no identificador sub estável do provedor, nunca no e-mail sozinho. E-mails mudam, são reciclados e — a aresta afiada — nem sempre são verificados: uma classe de vulnerabilidades de 2023 mostrou que apps que confiavam em um claim de e-mail não verificado nos tokens de um grande provedor de identidade ficavam abertos a roubo de conta por qualquer um capaz de definir aquele e-mail na própria conta do provedor. Vincule automaticamente só e-mails que o provedor atesta como verificados; caso contrário, peça ao usuário que vincule explicitamente. E planeje a saída: usuários bloqueados em um provedor (acontece sem aviso) perdem todos os apps rio abaixo, a menos que você tenha oferecido um segundo método vinculado — e é por isso que “um método de login por usuário” é um gerador de tickets de suporte fantasiado de simplicidade.

Casos de uso comuns

• Login em apps de consumo — o login social canônico: menos atrito, MFA herdada, nenhum banco de senhas para vazar.
• Acesso a APIs de terceiros — o caso original do OAuth: um app de agenda lendo o seu calendário sem a sua senha.
• Autenticação máquina a máquina — client credentials entre serviços, sem usuário à vista.
• Identidade multi-provedor — uma conta, vários métodos de login vinculados, desvinculação e recuperação por usuário.
• Ponte para SSO corporativo — o mesmo padrão OIDC apontado para um provedor de identidade corporativo em vez de um social.

Você deveria oferecer login social? Matriz de decisão

Limitações e trade-offs

• Você herda as decisões do provedor. Telas de consentimento, duração de sessão, recuperação de conta e deprecações acontecem no cronograma dele, não no seu.
• O risco de concentração é real. Uma queda do provedor ou um bloqueio de conta é uma queda do seu login; métodos vinculados de reserva são a mitigação, não um extra opcional.
• A flexibilidade do OAuth é sua fraqueza histórica. Um framework cheio de opções convida combinações inseguras — o 2.1 existe porque fluxos implicit, redirects com curinga e refresh tokens sem rotação continuavam indo para produção.
• Fluxos de redirect têm arestas afiadas. state (CSRF), redirect URIs exatas (open redirect e roubo de código) e PKCE (interceptação) estão cada um a um parâmetro esquecido de um incidente.
• Claims sociais são um piso, não um perfil. Você recebe subject, e-mail, nome — atributos além disso ainda exigem o seu próprio onboarding, e relays de privacidade significam que até o e-mail pode ser um alias.

OAuth e login social no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Os fluxos acima colapsam nas abas de código: o cliente obtém os tokens do provedor nativamente, os entrega ao logInWith, e os adaptadores de autenticação do Back4app os verificam no servidor junto ao provedor antes de criar ou encontrar o User — as identidades de provedor vivem em blocos authData por provedor, ancorados no subject estável, que é a regra de vinculação de contas imposta por construção. O linkWith acopla provedores adicionais (ou uma credencial de e-mail) ao mesmo usuário, respondendo ao problema do bloqueio em uma chamada, e o token de sessão que seu app recebe funciona nas APIs REST, GraphQL e Live Query, com ACLs e permissões em nível de classe decidindo o que ele pode tocar. A dança de redirects, a verificação de tokens e os casos-limite de vinculação chegam como comportamento de plataforma — você configura os provedores no painel e entrega o botão.