¿Qué son OAuth 2.0 y el Login Social?

OAuth 2.0 es un estándar de autorización que permite a una app acceder a tu cuenta en otro servicio — el login social construye el inicio de sesión encima. Los dos suelen explicarse por separado, y así es como la confusión sobrevive: el RFC 6749 define la plomería (acceso delegado y con scope, sin compartir contraseñas), OpenID Connect agrega la capa de identidad, y el botón de “Iniciar sesión con…” es la funcionalidad de producto montada sobre ambos.

Puntos clave

El flujo authorization code, paso a paso

La danza de redirects detrás de cada pantalla de consentimiento — con los parámetros que importan:

1  App → proveedor    /authorize?client_id=…&redirect_uri=…&scope=profile
                      &state=af3G…            ← guarda anti-CSRF, verificada a la vuelta
                      &code_challenge=hK9…    ← PKCE: hash de un secreto recién creado

2  Usuario ↔ proveedor   Inicia sesión ALLÁ (la contraseña nunca toca la app) y consiente

3  Proveedor → app    redirect_uri?code=SplxlO…&state=af3G…   ← código de un solo uso

4  App → proveedor    POST /token  { code, code_verifier }    ← prueba de PKCE
   Proveedor → app    { access_token, refresh_token, id_token }

5  App → API          Authorization: Bearer <access_token>

Así se ve cuando un backend lo envuelve — tokens del proveedor entran, sesión verificada sale:

// 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)
}

Los cuatro roles

Grant types: qué flujo usar y qué cambió OAuth 2.1

OAuth 2.1 es consolidación, no revolución: las eliminaciones de arriba, más redirect URIs de coincidencia exacta y la prohibición de bearer tokens en query strings — las lecciones de seguridad acumuladas de una década plegadas de vuelta en un solo documento. Los explicadores definicionales en gran parte no se han puesto al día; varios todavía enseñan el flujo implicit sin ninguna advertencia.

OAuth vs. OpenID Connect: autorización vs. autenticación

La frase que todo el mundo repite — “OAuth no es autenticación” — merece su mecanismo, porque el mecanismo es lo que vuelve explotable el login ingenuo:

“Iniciar sesión con un access token a secas” falla porque los access tokens son evidencia transferible de permiso, no de presencia: una app maliciosa que obtuvo un token para sus propios fines podría reproducirlo en otro lugar para hacerse pasar por el usuario. OpenID Connect existe precisamente para cerrar esa brecha — los mismos flujos, más una aserción de identidad vinculada criptográficamente a tu app.

Login social: el botón encima de la plomería

El login social es OIDC empaquetado como UX: el proveedor autentica, tu app recibe claims verificados y crea o encuentra una cuenta — ninguna contraseña almacenada, ningún flujo de restablecimiento que mantener, la MFA del proveedor heredada gratis. Los trade-offs de producto merecen números honestos. Las afirmaciones de 20–50% de aumento en registros son folclore de proveedor; las pruebas controladas han medido algo más cercano al 3% — aunque cerca de un tercio de los inicios de sesión de consumo hoy llega por la vía social, señal clara de que los usuarios quieren la opción. Las prácticas que de verdad mueven la conversión: ofrece dos o tres proveedores que tu audiencia usa (la “parrilla de salida” de botones perjudica de forma medible), mantén siempre la alternativa por email, y ten presente que los redirects de OAuth se rompen dentro de WebViews embebidas en apps — una causa real de fallas de registro en mobile. Dos datos específicos de proveedor pesan lo suficiente para nombrarlos: Sign in with Apple emite direcciones de relay privado (…@privaterelay.appleid.com), así que la vinculación por email y las listas de correo deben esperar aliases opacos — y las reglas de la App Store exigen que las apps que ofrecen login de terceros ofrezcan también el de Apple.

Vinculación de cuentas y la trampa del email

La misma persona va a llegar desde dos proveedores, y ambos van a reportar [email protected]. La regla que evita la vulnerabilidad clásica: la identidad se ancla en el identificador sub estable del proveedor, nunca en el email solo. Los emails cambian, se reciclan y — el filo cortante — no siempre están verificados: una clase de vulnerabilidades de 2023 mostró que las apps que confiaban en un claim de email no verificado en los tokens de un gran proveedor quedaban abiertas a robo de cuenta por cualquiera capaz de fijar ese email en su propia cuenta del proveedor. Vincula automáticamente solo emails que el proveedor atestigua como verificados; de lo contrario, pídele al usuario que vincule de forma explícita. Y planifica la salida: los usuarios bloqueados en un proveedor (pasa sin aviso) pierden todas las apps río abajo, a menos que hayas ofrecido un segundo método vinculado — por eso “un método de login por usuario” es un generador de tickets de soporte disfrazado de simplicidad.

Casos de uso comunes

• Inicio de sesión en apps de consumo — el login social canónico: menos fricción, MFA heredada, ninguna base de contraseñas que vulnerar.
• Acceso a APIs de terceros — el caso original de OAuth: una app de agenda leyendo tu calendario sin tu contraseña.
• Autenticación máquina a máquina — client credentials entre servicios, sin usuario a la vista.
• Identidad multiproveedor — una cuenta, varios métodos de login vinculados, desvinculación y recuperación por usuario.
• Puente hacia SSO empresarial — el mismo patrón OIDC apuntado a un proveedor de identidad corporativo en lugar de uno social.

¿Deberías ofrecer login social? Matriz de decisión

Limitaciones y trade-offs

• Heredas las decisiones del proveedor. Pantallas de consentimiento, duración de sesiones, recuperación de cuentas y deprecaciones ocurren en su calendario, no en el tuyo.
• El riesgo de concentración es real. Una caída del proveedor o un bloqueo de cuenta es una caída de tu login; los métodos vinculados de respaldo son la mitigación, no un extra opcional.
• La flexibilidad de OAuth es su debilidad histórica. Un framework con opciones invita combinaciones inseguras — el 2.1 existe porque flujos implicit, redirects con comodín y refresh tokens sin rotación seguían llegando a producción.
• Los flujos de redirect tienen filos cortantes. state (CSRF), redirect URIs exactas (open redirect y robo de código) y PKCE (interceptación) están cada uno a un parámetro olvidado de un incidente.
• Los claims sociales son un piso, no un perfil. Recibes subject, email, nombre — los atributos más allá de eso siguen necesitando tu propio onboarding, y los relays de privacidad significan que hasta el email puede ser un alias.

OAuth y el 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. Los flujos de arriba colapsan en las pestañas de código: el cliente obtiene los tokens del proveedor de forma nativa, se los entrega a logInWith, y los adaptadores de autenticación de Back4app los verifican del lado del servidor contra el proveedor antes de crear o encontrar el User — las identidades de proveedor viven en bloques authData por proveedor, anclados en el subject estable, que es la regla de vinculación de cuentas impuesta por construcción. linkWith acopla proveedores adicionales (o una credencial de email) al mismo usuario, respondiendo al problema del bloqueo en una sola llamada, y el token de sesión que tu app recibe funciona en las APIs REST, GraphQL y Live Query, con ACLs y permisos a nivel de clase decidiendo qué puede tocar. La danza de redirects, la verificación de tokens y los casos límite de vinculación llegan como comportamiento de plataforma — configuras los proveedores en el panel y entregas el botón.