---
term: 'Adaptadores de Login Social: Integração OAuth em BaaS'
seoTitle: 'Adaptadores de Login Social: Integração OAuth em BaaS'
headline: 'O que são adaptadores de login social?'
slug: adaptadores-de-login-social
category: auth-security
shortDefinition: 'Um adaptador de login social é um componente de backend que verifica tokens de um provedor de identidade e os converte em usuário e sessão.'
relatedTerms:
  - oauth-2-social-login
  - single-sign-on-sso
  - identity-access-management-iam
  - json-web-token-jwt
contrastsWith:
  - oauth-2-social-login
faq:
  - question: 'O que é um adaptador de login social?'
    answer: 'É a camada de tradução, do lado da plataforma, entre um provedor de identidade e a sua tabela de usuários. O cliente obtém tokens do provedor; o adaptador os verifica no servidor junto àquele provedor, extrai o subject ID estável e então cria ou encontra o registro de usuário e emite a sessão do seu próprio app. Um adaptador por provedor, um modelo uniforme de usuário e sessão do seu lado.'
  - question: 'Qual a diferença entre um adaptador de autenticação e o OAuth em si?'
    answer: 'OAuth 2.0 e OpenID Connect definem o protocolo — fluxos, tokens, claims. O adaptador é um componente de implementação que consome a saída do protocolo: valida os tokens do provedor, mapeia para uma conta local e cuida de vinculação e upgrades. Implementar OAuth na mão significa assumir redirects, troca de tokens e verificação; um adaptador significa que a plataforma assume tudo depois que os tokens chegam.'
  - question: 'O que é authData?'
    answer: 'É o bloco de identidade por provedor guardado no registro do usuário — para cada provedor vinculado, o subject ID estável e as credenciais que o adaptador verificou. Um usuário logado por dois provedores carrega duas entradas de authData apontando para uma conta só. Como o casamento usa o subject ID do provedor em vez do e-mail, a clássica tomada de conta por e-mail reciclado fica eliminada por construção.'
  - question: 'Como funciona a vinculação de contas em um BaaS?'
    answer: 'Uma chamada de vinculação anexa os tokens verificados de um provedor adicional ao usuário logado no momento, em vez de criar uma conta nova. O adaptador verifica o token do novo provedor exatamente como faria no login e então grava um segundo bloco de authData. Depois disso, qualquer um dos provedores entra na mesma conta — a resposta padrão para usuários que chegam por botões diferentes em dispositivos diferentes.'
  - question: 'Dá para transformar um usuário anônimo em login social?'
    answer: 'Sim — esse é um dos melhores truques do padrão. Uma sessão de convidado apoiada num usuário anônimo acumula objetos reais: um carrinho, preferências, progresso de jogo. Vincular um provedor a esse usuário o converte no lugar em uma conta identificada; todo objeto, ACL e relação sobrevive porque o ID do usuário nunca muda. Sem script de migração, sem cópia de dados.'
  - question: 'O backend chega a ver a senha do usuário no provedor?'
    answer: 'Não. O usuário se autentica na superfície do próprio provedor — o app ou a página dele — e o cliente recebe apenas tokens. O adaptador vê esses tokens, verifica-os com o provedor e guarda o subject ID. Essa é a promessa central do OAuth levada até o fim: seu backend não guarda nenhuma senha de terceiros, e um vazamento da sua tabela de usuários não expõe credencial de provedor nenhuma.'
  - question: 'O que acontece quando o token do provedor expira?'
    answer: 'Nada visível, em geral. Os tokens do provedor são necessários no login e na vinculação — assim que o adaptador os verifica e emite a sessão da sua plataforma, essa sessão vive pelas suas regras, não pelo tempo de vida do token do provedor. O usuário só reautentica no provedor quando a sua sessão termina ou é revogada; o adaptador então verifica um token novo e o ciclo recomeça.'
  - question: 'Dá para adicionar um provedor que a plataforma não suporta?'
    answer: 'Em geral sim — sistemas de adaptadores costumam ser plugáveis. Um adaptador customizado implementa uma interface pequena de verificação: dado o authData que o cliente envia, confirme com o serviço emissor e devolva sucesso ou falha. Isso torna o padrão extensível a provedores de nicho, pontes para SSO corporativo ou qualquer serviço capaz de atestar uma identidade, sem tocar na maquinaria de sessão da plataforma.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'RFC 6749 — The OAuth 2.0 Authorization Framework'
    url: 'https://datatracker.ietf.org/doc/html/rfc6749'
  - name: 'OpenID Connect Core 1.0'
    url: 'https://openid.net/specs/openid-connect-core-1_0.html'
  - name: 'OAuth 2.0 reference (oauth.net)'
    url: 'https://oauth.net/2/'
  - name: 'Third-party authentication guide'
    url: 'https://docs.parseplatform.org/parse-server/guide/#oauth-and-3rd-party-authentication'
cta:
  title: 'Login social em uma chamada de método'
  text: 'O Back4app já traz adaptadores de autenticação para os principais provedores de identidade: entregue os tokens do provedor ao SDK e a plataforma os verifica no servidor, cria ou encontra o usuário e emite a sua sessão — com linkWith cobrindo vinculação de contas e upgrade de convidados.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-25'
translationKey: social-auth-adapters-oauth
---

**Um adaptador de login social é um componente de backend que verifica tokens de um provedor de identidade e os converte em usuário e sessão.** Ele é o miolo que falta em toda explicação de login social: o [OAuth 2.0](/glossary/pt/oauth-2-login-social/) descreve como o cliente obtém os tokens do provedor, mas alguma coisa do seu lado ainda precisa verificar esses tokens, decidir a que conta pertencem e emitir uma sessão em que as suas APIs confiem. Essa coisa é o adaptador.

## Principais pontos

| Pergunta | Resposta |
| --- | --- |
| O que é | A camada da plataforma que vira tokens verificados do provedor no seu usuário + sessão |
| vs. OAuth puro | OAuth é o protocolo; o adaptador é quem consome a saída dele no backend |
| A chave de identidade | O subject ID estável do provedor, guardado por provedor em `authData` |
| Os fluxos que ele assume | Login, vinculação de contas (`linkWith`), upgrade de anônimo para identificado |
| O que você nunca guarda | A senha do usuário no provedor — só tokens, verificados no servidor |

## O adaptador em ação

Tokens do provedor entram, sessão verificada sai — mais o fluxo de upgrade de convidado:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// The adapter path: provider tokens in, verified session out.
// The platform verifies the token with the provider before any user exists.
const user = await Parse.User.logInWith('apple', {
  authData: { id: providerUserId, token: identityToken },
});
// user.authData holds the provider block, keyed on the stable subject ID

// Anonymous → identified: upgrade the guest without losing its objects
const guest = await Parse.AnonymousUtils.logIn();
await guest.linkWith('apple', {
  authData: { id: providerUserId, token: identityToken },
});
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The adapter path: provider tokens in, verified session out
final user = ParseUser.forQuery();
final response = await user.loginWith(
  'apple',
  apple(identityToken, providerUserId),
);
// First login creates the user; later logins match the same authData

// Anonymous → identified: upgrade the guest without losing its objects
final guest = ParseUser.forQuery();
await guest.loginAnonymous();
await guest.linkWith('apple', apple(identityToken, providerUserId));
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The adapter path: provider tokens in, verified session out
let user = try await User.apple.login(
    user: providerUserId,
    identityToken: tokenData
)
// First login creates the user; later logins match the same authData

// Anonymous → identified: upgrade the guest without losing its objects
let guest = try await User.anonymous.login()
let upgraded = try await guest.apple.link(
    user: providerUserId,
    identityToken: tokenData
)
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The adapter path: provider tokens in, verified session out
val authData = mapOf("id" to providerUserId, "token" to identityToken)
ParseUser.logInWithInBackground("apple", authData).continueWith { task ->
    val user = task.result // created on first login, matched afterwards
}

// Anonymous → identified: upgrade the guest without losing its objects
ParseAnonymousUtils.logIn { guest, e ->
    if (e == null && guest != null) {
        guest.linkWithInBackground("apple", authData)
    }
}
```

## O que o adaptador de fato faz

A parte do cliente no login social termina quando um grande provedor de identidade lhe entrega tokens. A parte do adaptador começa aí, e é toda no servidor:

```mermaid
flowchart LR
  accTitle: Como um adaptador de login social transforma tokens do provedor em sessão da plataforma
  accDescr: O cliente se autentica em um provedor de identidade e recebe tokens; ele os envia como authData ao backend, onde o adaptador específico do provedor verifica os tokens diretamente com o provedor, encontra ou cria um registro de usuário indexado pelo subject ID estável e devolve ao cliente o token de sessão da própria plataforma.
  C["App cliente"] -->|"1 · autentica no<br/>provedor de identidade"| P["Provedor de identidade"]
  P -->|"2 · tokens"| C
  C -->|"3 · authData"| A["Adaptador de auth<br/>(backend)"]
  A -->|"4 · verifica os tokens"| P
  A -->|"5 · encontra ou cria<br/>pelo subject ID"| U[("Tabela de usuários<br/>blocos authData")]
  A -->|"6 · token de sessão da plataforma"| C
```

O passo 4 é o que implementações caseiras pulam por sua conta e risco: o adaptador chama o provedor para confirmar que o token é genuíno, não expirou e foi emitido para este app — "verificação" no cliente não prova nada, já que qualquer requisição pode alegar qualquer identidade. O passo 5 codifica a regra de vinculação que evita a tomada de conta clássica: o casamento usa o subject ID estável do provedor, nunca uma claim de e-mail. O resultado na tabela de usuários é um mapa `authData` — um bloco verificado por provedor vinculado, todos apontando para um único usuário cujos objetos, [ACLs](/glossary/pt/listas-de-controle-de-acesso-acl/) e sessões se comportam exatamente como se a conta tivesse senha.

## Adaptador de autenticação vs. OAuth feito na mão

| Aspecto | Com adaptador | Feito na mão |
| --- | --- | --- |
| Verificação de token | A plataforma chama o provedor no servidor | Você implementa por provedor, e mantém atualizado |
| Casamento de contas | Indexado pelo subject ID estável por construção | Seu schema, seus bugs — indexar por e-mail é o clássico |
| Vinculação de contas | Uma chamada `linkWith` | Tabelas próprias e lógica de merge |
| Upgrade de convidado | `linkWith` no usuário anônimo, no lugar | Migração manual de dados entre contas |
| Emissão de sessão | Sessão da plataforma, uniforme entre provedores | Faça a sua em cima de [JWTs](/glossary/pt/json-web-token-jwt/) |
| Provedor novo | Configure (ou encaixe um adaptador customizado) | Mais uma implementação de cliente OAuth |

A ideia para internalizar: o adaptador não substitui o OAuth — o cliente continua rodando o fluxo do provedor e o PKCE continua importando. Ele substitui tudo o que você construiria *depois* que os tokens chegam, que é exatamente onde mora a maioria das vulnerabilidades de login social.

## Vinculação, e o upgrade que salva o seu onboarding

Dois fluxos separam a autenticação por adaptador de um mero endpoint "verifique este token". **Vinculação de contas**: a mesma pessoa chega por botões diferentes — a chamada de vinculação anexa o bloco verificado de um segundo provedor ao usuário logado, de modo que qualquer provedor alcança uma única conta e um bloqueio no provedor deixa de significar cliente perdido. **Upgrade de anônimo**: apps que deixam convidados agir de imediato apoiam o convidado num usuário anônimo; quando o usuário enfim entra, a vinculação converte esse usuário no lugar — mesmo object ID, então o carrinho, o progresso e as permissões por objeto sobrevivem. Times que adiam o cadastro assim removem sua tela de maior atrito sem um script de migração esperando no fim. O mesmo mecanismo roda ao contrário como desvinculação, que é como usuários aposentam um provedor sem perder a conta — configurações de [single sign-on](/glossary/pt/single-sign-on-sso/) usam isso ao consolidar identidades sob um provedor corporativo.

## Casos de uso comuns

- **Login de consumidor com grandes provedores de identidade** — os botões de sempre, com verificação, casamento e sessões resolvidos uma vez, de forma uniforme.
- **Onboarding guest-first** — usuários anônimos convertidos no lugar no momento do compromisso, sem perda de dados.
- **Contas multiprovedor** — um usuário, vários métodos de login vinculados, desvinculação por usuário; a resposta ao bloqueio de provedor.
- **Pontes de identidade corporativa** — um adaptador customizado apontado para um sistema de [IAM](/glossary/pt/iam/) da empresa em vez de um provedor social.
- **Continuidade entre dispositivos** — a sessão da plataforma funciona em REST, GraphQL e live queries, não importa qual provedor a abriu.

## Você deveria usar um adaptador ou construir o fluxo por conta própria? Matriz de decisão

| Sua situação | Tenda para |
| --- | --- |
| Provedores padrão, fluxos padrão | Adaptador — este é o caminho commodity |
| Você precisa processar claims customizadas no meio do fluxo | Feito na mão, ou um adaptador customizado se a plataforma permitir |
| Time pequeno, autenticação não é o seu produto | Adaptador — bug de verificação de token é material de vazamento |
| Você já opera um serviço de identidade | Faça a ponte com um adaptador customizado em vez de duplicá-lo |
| Compliance exige ser dono de cada byte da autenticação | Feito na mão sobre componentes open-source auditáveis |
| Convidados precisam converter sem perder dados | Adaptador — a vinculação no lugar é a feature inteira |

## Limitações e trade-offs

- **Você herda a lista de provedores da plataforma.** Os provedores mainstream estão cobertos; um de nicho significa escrever um adaptador customizado ou esperar o roadmap.
- **O fluxo do lado do cliente continua sendo seu.** O adaptador começa no envio do token — UX de login nativo, redirects e PKCE seguem sendo trabalho de cliente, e restrições de WebView in-app ainda incomodam.
- **A política do provedor atravessa tudo.** Telas de consentimento, formatos de token, e-mails de relay e descontinuações mudam no calendário do provedor; o adaptador absorve a mecânica, não a política.
- **O debug abrange três partes.** Um login que falha pode nascer no fluxo do cliente, na chamada de verificação do adaptador ou no provedor — bons logs na fronteira do adaptador valem o esforço no primeiro dia.
- **A uniformidade corta dos dois lados.** O adaptador normaliza todo provedor para subject ID mais perfil; se o seu app precisa de dados específicos de um provedor, você vai acabar chamando as APIs dele à parte de qualquer jeito.

## Adaptadores de 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. Seus adaptadores de autenticação implementam tudo o que está neste artigo como [comportamento de plataforma](https://docs.parseplatform.org/parse-server/guide/#oauth-and-3rd-party-authentication): `logInWith` verifica os tokens do provedor no servidor e cria ou encontra o usuário pelo subject ID estável, `linkWith` cuida tanto da vinculação de contas quanto do upgrade de usuários anônimos no lugar, e a sessão resultante funciona em todas as APIs, com CLPs e ACLs decidindo no que ela pode tocar. Os provedores são configurados no dashboard, e a interface de adaptador é aberta — um provedor customizado é um pequeno módulo de verificação, não um fork da sua stack de autenticação.