---
term: 'Adaptadores de Login Social: Integración OAuth en BaaS'
seoTitle: 'Adaptadores de Login Social: Integración OAuth en BaaS'
headline: '¿Qué son los adaptadores de login social?'
slug: adaptadores-de-login-social
category: auth-security
shortDefinition: 'Un adaptador de login social es un componente de backend que verifica tokens de un proveedor de identidad y los convierte en usuario y sesión.'
relatedTerms:
  - oauth-2-social-login
  - single-sign-on-sso
  - identity-access-management-iam
  - json-web-token-jwt
contrastsWith:
  - oauth-2-social-login
faq:
  - question: '¿Qué es un adaptador de login social?'
    answer: 'La capa de traducción, del lado de la plataforma, entre un proveedor de identidad y tu tabla de usuarios. El cliente obtiene tokens del proveedor; el adaptador los verifica en el servidor contra ese proveedor, extrae el subject ID estable y entonces crea o encuentra el registro de usuario y emite la sesión de tu propia app. Un adaptador por proveedor, un modelo uniforme de usuario y sesión de tu lado.'
  - question: '¿En qué se diferencia un adaptador de autenticación del propio OAuth?'
    answer: 'OAuth 2.0 y OpenID Connect definen el protocolo — flujos, tokens, claims. Un adaptador es un componente de implementación que consume la salida del protocolo: valida los tokens del proveedor, los mapea a una cuenta local y maneja la vinculación y los upgrades. Implementar OAuth a mano significa asumir los redirects, el intercambio de tokens y la verificación; un adaptador significa que la plataforma asume todo lo que ocurre después de que los tokens llegan.'
  - question: '¿Qué es authData?'
    answer: 'El bloque de identidad por proveedor guardado en el registro del usuario — para cada proveedor vinculado, el subject ID estable y las credenciales que el adaptador verificó. Un usuario que inició sesión por dos proveedores lleva dos entradas de authData apuntando a una sola cuenta. Como el emparejamiento usa el subject ID del proveedor y no el email, la clásica toma de cuentas por email reciclado queda eliminada por diseño.'
  - question: '¿Cómo funciona la vinculación de cuentas en un BaaS?'
    answer: 'Una llamada de vinculación adjunta los tokens verificados de un proveedor adicional al usuario con sesión activa, en lugar de crear una cuenta nueva. El adaptador verifica el token del nuevo proveedor exactamente como en el login y luego escribe un segundo bloque de authData. Después, cualquiera de los dos proveedores entra a la misma cuenta — la respuesta estándar para usuarios que llegan por botones distintos en dispositivos distintos.'
  - question: '¿Se puede convertir un usuario anónimo en un login social?'
    answer: 'Sí — ese es uno de los mejores trucos del patrón. Una sesión de invitado respaldada por un usuario anónimo acumula objetos reales: un carrito, preferencias, progreso de juego. Vincular un proveedor a ese usuario lo convierte en el lugar en una cuenta identificada; cada objeto, ACL y relación sobrevive porque el ID del usuario nunca cambia. Sin script de migración, sin copia de datos.'
  - question: '¿El backend llega a ver la contraseña del usuario en el proveedor?'
    answer: 'No. El usuario se autentica en la superficie del propio proveedor — su app o su página web — y el cliente recibe solo tokens. El adaptador ve esos tokens, los verifica con el proveedor y guarda el subject ID. Esta es la promesa central de OAuth llevada hasta el final: tu backend no guarda ninguna contraseña de terceros, y una brecha en tu tabla de usuarios no expone credenciales de ningún proveedor.'
  - question: '¿Qué pasa cuando el token del proveedor expira?'
    answer: 'Nada visible, por lo general. Los tokens del proveedor se necesitan al iniciar sesión y al vincular — una vez que el adaptador los verifica y emite la sesión de tu plataforma, esa sesión vive según tus reglas, no según la vida útil del token del proveedor. El usuario solo se reautentica con el proveedor cuando tu sesión termina o es revocada; el adaptador verifica entonces un token fresco y el ciclo se repite.'
  - question: '¿Se puede agregar un proveedor que la plataforma no soporta?'
    answer: 'En general sí — los sistemas de adaptadores suelen ser conectables. Un adaptador personalizado implementa una pequeña interfaz de verificación: dado el authData que un cliente envía, confírmalo con el servicio emisor y devuelve éxito o fallo. Eso vuelve el patrón extensible a proveedores de identidad de nicho, puentes de SSO empresarial o cualquier servicio capaz de atestiguar una identidad, sin tocar la maquinaria de sesiones de la 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 en una sola llamada de método'
  text: 'Back4app trae adaptadores de autenticación para los principales proveedores de identidad: entrega al SDK los tokens del proveedor y la plataforma los verifica en el servidor, crea o encuentra al usuario y emite tu sesión — con linkWith cubriendo la vinculación de cuentas y los upgrades de invitados.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-04'
translationKey: social-auth-adapters-oauth
---

**Un adaptador de login social es un componente de backend que verifica tokens de un proveedor de identidad y los convierte en usuario y sesión.** Es el eslabón que falta en toda explicación del login social: [OAuth 2.0](/glossary/es/oauth-2-login-social/) describe cómo el cliente obtiene los tokens del proveedor, pero algo de tu lado todavía debe verificar esos tokens, decidir a qué cuenta pertenecen y acuñar una sesión en la que tus APIs confíen. Ese algo es el adaptador.

## Puntos clave

| Pregunta | Respuesta |
| --- | --- |
| Qué es | La capa de la plataforma que convierte tokens verificados del proveedor en tu usuario + sesión |
| vs. OAuth puro | OAuth es el protocolo; el adaptador es quien consume su salida en el backend |
| La clave de identidad | El subject ID estable del proveedor, guardado por proveedor en `authData` |
| Los flujos que asume | Login, vinculación de cuentas (`linkWith`), upgrade de anónimo a identificado |
| Lo que nunca guardas | La contraseña del usuario en el proveedor — solo tokens, verificados en el servidor |

## El adaptador en acción

Entran tokens del proveedor, sale una sesión verificada — más el flujo de upgrade de invitado:

**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)
    }
}
```

## Qué hace realmente el adaptador

La parte del cliente en el login social termina cuando un gran proveedor de identidad le entrega tokens. La parte del adaptador empieza ahí, y ocurre toda en el servidor:

```mermaid
flowchart LR
  accTitle: Cómo un adaptador de login social convierte tokens del proveedor en una sesión de la plataforma
  accDescr: El cliente se autentica con un proveedor de identidad y recibe tokens; los envía como authData al backend, donde el adaptador específico del proveedor verifica los tokens directamente con el proveedor, encuentra o crea un registro de usuario indexado por el subject ID estable y devuelve al cliente el token de sesión de la propia plataforma.
  C["App cliente"] -->|"1 · se autentica en el<br/>proveedor de identidad"| P["Proveedor de identidad"]
  P -->|"2 · tokens"| C
  C -->|"3 · authData"| A["Adaptador de auth<br/>(backend)"]
  A -->|"4 · verifica los tokens"| P
  A -->|"5 · encuentra o crea<br/>por subject ID"| U[("Tabla de usuarios<br/>bloques authData")]
  A -->|"6 · token de sesión de la plataforma"| C
```

El paso 4 es el que las implementaciones caseras se saltan bajo su propio riesgo: el adaptador llama al proveedor para confirmar que el token es genuino, no ha expirado y fue emitido para esta app — la "verificación" del lado del cliente no prueba nada, porque cualquier solicitud puede alegar cualquier identidad. El paso 5 codifica la regla de emparejamiento que evita la toma de cuentas clásica: se empareja por el subject ID estable del proveedor, nunca por una claim de email. El resultado en la tabla de usuarios es un mapa `authData` — un bloque verificado por proveedor vinculado, todos apuntando a un único usuario cuyos objetos, [ACLs](/glossary/es/listas-de-control-de-acceso-acl/) y sesiones se comportan exactamente como si la cuenta tuviera contraseña.

## Adaptador de autenticación vs. OAuth hecho a mano

| Aspecto | Con adaptador | Hecho a mano |
| --- | --- | --- |
| Verificación de tokens | La plataforma llama al proveedor en el servidor | Lo implementas por proveedor, y lo mantienes al día |
| Emparejamiento de cuentas | Indexado por el subject ID estable por construcción | Tu esquema, tus bugs — indexar por email es el clásico |
| Vinculación de cuentas | Una llamada `linkWith` | Tablas propias y lógica de merge |
| Upgrade de invitado | `linkWith` sobre un usuario anónimo, en el lugar | Migración manual de datos entre cuentas |
| Emisión de sesión | Sesión de la plataforma, uniforme entre proveedores | Arma la tuya sobre [JWTs](/glossary/es/json-web-token-jwt/) |
| Proveedor nuevo | Configúralo (o encaja un adaptador personalizado) | Otra implementación más de cliente OAuth |

La idea para internalizar: el adaptador no reemplaza a OAuth — el cliente sigue ejecutando el flujo del proveedor y PKCE sigue importando. Reemplaza todo lo que de otro modo construirías *después* de que los tokens llegan, que es exactamente donde viven la mayoría de las vulnerabilidades del login social.

## La vinculación, y el upgrade que salva tu onboarding

Dos flujos distinguen la autenticación por adaptador de un simple endpoint "verifica este token". **Vinculación de cuentas**: la misma persona llega por botones distintos — la llamada de vinculación adjunta el bloque verificado de un segundo proveedor al usuario con sesión activa, de modo que cualquier proveedor alcanza una sola cuenta y un bloqueo en el proveedor deja de ser un cliente perdido. **Upgrade de anónimo**: las apps que dejan actuar a los invitados de inmediato respaldan al invitado con un usuario anónimo; cuando el usuario por fin inicia sesión, la vinculación convierte a ese usuario en el lugar — mismo object ID, así que el carrito, el progreso y los permisos por objeto sobreviven. Los equipos que aplazan el registro así eliminan su pantalla de mayor fricción sin un script de migración esperando al final. El mismo mecanismo corre en reversa como desvinculación, que es como los usuarios retiran un proveedor sin perder la cuenta — las configuraciones de [single sign-on](/glossary/es/single-sign-on-sso/) lo usan al consolidar identidades bajo un proveedor corporativo.

## Casos de uso comunes

- **Inicio de sesión de consumidor con los grandes proveedores de identidad** — los botones de siempre, con verificación, emparejamiento y sesiones resueltos una sola vez, de forma uniforme.
- **Onboarding guest-first** — usuarios anónimos convertidos en el lugar en el momento del compromiso, sin pérdida de datos.
- **Cuentas multiproveedor** — un usuario, varios métodos de login vinculados, desvinculación por usuario; la respuesta al bloqueo de proveedor.
- **Puentes de identidad empresarial** — un adaptador personalizado apuntado a un sistema de [IAM](/glossary/es/iam/) corporativo en lugar de un proveedor social.
- **Continuidad entre dispositivos** — la sesión de la plataforma funciona en REST, GraphQL y live queries sin importar qué proveedor la abrió.

## ¿Deberías usar un adaptador de auth o construir el flujo tú mismo? Matriz de decisión

| Tu situación | Inclínate por |
| --- | --- |
| Proveedores estándar, flujos estándar | Adaptador — este es el camino commodity |
| Necesitas procesar claims personalizadas a mitad del flujo | Hecho a mano, o un adaptador personalizado si la plataforma lo permite |
| Equipo pequeño, la autenticación no es tu producto | Adaptador — los bugs de verificación de tokens son material de brecha |
| Ya operas un servicio de identidad | Tiéndele un puente con un adaptador personalizado en vez de duplicarlo |
| El compliance exige ser dueño de cada byte de la autenticación | Hecho a mano sobre componentes open-source auditables |
| Los invitados deben convertirse sin perder datos | Adaptador — la vinculación en el lugar es la feature entera |

## Limitaciones y trade-offs

- **Heredas la lista de proveedores de la plataforma.** Los proveedores mainstream están cubiertos; uno de nicho significa escribir un adaptador personalizado o esperar el roadmap.
- **El flujo del lado del cliente sigue siendo tuyo.** El adaptador empieza en el envío del token — la UX de login nativo, los redirects y PKCE siguen siendo trabajo de cliente, y las restricciones de WebView dentro de apps todavía muerden.
- **La política del proveedor se filtra hacia ti.** Las pantallas de consentimiento, los formatos de token, los emails de relay y las deprecaciones cambian según el calendario del proveedor; el adaptador absorbe la mecánica, no la política.
- **El debugging abarca tres partes.** Un login fallido puede originarse en el flujo del cliente, en la llamada de verificación del adaptador o en el proveedor — unos buenos logs en la frontera del adaptador valen la pena desde el primer día.
- **La uniformidad corta en ambos sentidos.** El adaptador normaliza cada proveedor a subject ID más perfil; si tu app necesita datos profundos específicos de un proveedor, terminarás llamando a las APIs de ese proveedor por separado de todos modos.

## Adaptadores de login social en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Sus adaptadores de autenticación implementan todo lo de este artículo como [comportamiento de plataforma](https://docs.parseplatform.org/parse-server/guide/#oauth-and-3rd-party-authentication): `logInWith` verifica los tokens del proveedor en el servidor y crea o encuentra al usuario por el subject ID estable, `linkWith` maneja tanto la vinculación de cuentas como los upgrades de usuarios anónimos en el lugar, y la sesión resultante funciona en todas las APIs, con CLPs y ACLs decidiendo qué puede tocar. Los proveedores se configuran en el dashboard, y la interfaz de adaptadores es abierta — un proveedor personalizado es un pequeño módulo de verificación, no un fork de tu stack de autenticación.