What are OAuth 2.0 & Social Login?

OAuth 2.0 is an authorization standard that lets apps access a user account on another service — social login builds sign-in on top. The two are usually explained apart, which is how the confusion survives: RFC 6749 defines the plumbing (delegated, scoped access without sharing passwords), OpenID Connect adds the identity layer, and the “Sign in with…” button is the product feature riding both.

Key takeaways

The authorization code flow, step by step

The redirect dance behind every consent screen — with the parameters that matter:

1  App → provider     /authorize?client_id=…&redirect_uri=…&scope=profile
                      &state=af3G…            ← CSRF guard, checked on return
                      &code_challenge=hK9…    ← PKCE: hash of a fresh secret

2  User ↔ provider    Logs in THERE (password never touches the app), consents

3  Provider → app     redirect_uri?code=SplxlO…&state=af3G…   ← one-time code

4  App → provider     POST /token  { code, code_verifier }    ← PKCE proof
   Provider → app     { access_token, refresh_token, id_token }

5  App → API          Authorization: Bearer <access_token>

What that looks like when a backend wraps it — provider tokens in, verified session out:

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

The four roles

Grant types: which flow, and what OAuth 2.1 changed

OAuth 2.1 is consolidation, not revolution: the deprecations above plus exact-match redirect URIs and a ban on bearer tokens in query strings — the accumulated security lessons of a decade folded back into one document. Definitional explainers largely haven’t caught up; several still teach the implicit flow unflagged.

OAuth vs. OpenID Connect: authorization vs. authentication

The one-liner everyone repeats — “OAuth is not authentication” — deserves its mechanism, because the mechanism is what makes naive login exploitable:

“Login with a bare access token” fails because access tokens are transferable evidence of permission, not presence: a malicious app that obtained a token for its own purposes could replay it to impersonate the user elsewhere. OpenID Connect exists precisely to close that gap — same flows, plus an identity assertion cryptographically bound to your app.

Social login: the button on top of the plumbing

Social login is OIDC packaged as UX: the provider authenticates, your app receives verified claims and creates or matches an account — no password stored, no reset flow owned, the provider’s MFA inherited for free. The product trade-offs deserve honest numbers. Registration-lift claims of 20–50% are vendor lore; controlled tests have measured closer to 3%, though roughly a third of consumer sign-ins now arrive socially — users clearly want the option. The practices that actually move conversion: offer two or three providers your audience uses (the “NASCAR grid” of buttons measurably hurts), always keep an email fallback, and know that OAuth redirects break inside in-app WebViews — a real driver of mobile signup failure. Two provider-specific facts are load-bearing enough to name: Sign in with Apple issues private relay addresses (…@privaterelay.appleid.com), so email-keyed linking and mailing lists must expect opaque aliases — and Apple’s App Store rules require apps offering third-party sign-in to offer Apple’s as well.

Account linking and the email trap

The same person will arrive from two providers, and both will report [email protected]. The rule that prevents the classic vulnerability: identity keys on the provider’s stable sub identifier, never on email alone. Emails change, get recycled, and — the sharp edge — are not always verified: a 2023 vulnerability class showed apps that trusted an unverified email claim from a major provider’s tokens were open to account takeover by anyone who could set that email on their own provider account. Auto-link only on provider-attested verified emails; otherwise prompt the user to link explicitly. And plan for the exit: users locked out of a provider (it happens without warning) lose every app downstream unless you offered a second linked method — which is why “one login method per user” is a support-ticket generator wearing a simplicity costume.

Common use cases

• Consumer app sign-in — the canonical social login: lower friction, inherited MFA, no password database to breach.
• Third-party API access — the original OAuth case: a scheduling app reading your calendar without your password.
• Machine-to-machine auth — client credentials between services, no user in sight.
• Multi-provider identity — one account, several linked login methods, per-user unlink and recovery.
• Enterprise SSO bridging — the same OIDC pattern pointed at a workforce identity provider instead of a social one.

Should you offer social login? A decision matrix

Limitations and trade-offs

• You inherit the provider’s decisions. Consent screens, session lifetimes, account recovery, and deprecations happen on their schedule, not yours.
• Concentration risk is real. A provider outage or account lockout is your login outage; linked fallback methods are the mitigation, not an optional extra.
• OAuth’s flexibility is its historical weakness. A framework with options invites insecure combinations — the reason 2.1 exists is that implicit flows, wildcard redirects, and unrotated refresh tokens kept shipping.
• Redirect flows have sharp edges. state (CSRF), exact redirect URIs (open-redirect and code theft), and PKCE (interception) are each one missing parameter away from an incident.
• Social claims are a floor, not a profile. You get subject, email, name — attributes beyond that still need your own onboarding, and privacy relays mean even email may be an alias.

OAuth and social login on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The flows above collapse into the code tabs: the client obtains the provider’s tokens natively, hands them to logInWith, and Back4app’s auth adapters verify them server-side against the provider before creating or matching the User — provider identities live in per-provider authData blocks keyed on the stable subject ID, which is the account-linking rule enforced by construction. linkWith attaches additional providers (or an email credential) to the same user, answering the lockout problem in one call, and the session token your app receives then works across the REST, GraphQL, and Live Query APIs with ACLs and class-level permissions deciding what it may touch. The redirect dance, token verification, and linking edge cases arrive as platform behavior — you configure providers in the dashboard and ship the button.