Was sind OAuth 2.0 und Social Login?

OAuth 2.0 ist ein Autorisierungsstandard, mit dem Apps auf ein Nutzerkonto bei einem anderen Dienst zugreifen – Social Login baut die Anmeldung darauf auf. Beide werden meist getrennt erklärt, und genau so überlebt die Verwechslung: RFC 6749 definiert die Mechanik (delegierter Zugriff mit begrenztem Scope, ohne Passwörter zu teilen), OpenID Connect ergänzt die Identitätsschicht, und der “Anmelden mit …”-Button ist das Produkt-Feature, das auf beidem fährt.

Das Wichtigste in Kürze

Der Authorization-Code-Flow, Schritt für Schritt

Der Redirect-Tanz hinter jedem Zustimmungsdialog – mit den Parametern, auf die es ankommt:

1  App → Anbieter     /authorize?client_id=…&redirect_uri=…&scope=profile
                      &state=af3G…            ← CSRF-Schutz, beim Rücksprung geprüft
                      &code_challenge=hK9…    ← PKCE: Hash eines frischen Geheimnisses

2  Nutzer ↔ Anbieter  Meldet sich DORT an (Passwort berührt die App nie), stimmt zu

3  Anbieter → App     redirect_uri?code=SplxlO…&state=af3G…   ← Einmalcode

4  App → Anbieter     POST /token  { code, code_verifier }    ← PKCE-Nachweis
   Anbieter → App     { access_token, refresh_token, id_token }

5  App → API          Authorization: Bearer <access_token>

So sieht das aus, wenn ein Backend den Ablauf kapselt – Anbieter-Tokens hinein, verifizierte Session heraus:

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

Die vier Rollen

Grant Types: welcher Flow, und was OAuth 2.1 geändert hat

OAuth 2.1 ist Konsolidierung, keine Revolution: die Streichungen oben, dazu Redirect-URIs mit exakter Übereinstimmung und ein Verbot von Bearer Tokens in Query-Strings – die gesammelten Sicherheitslektionen eines Jahrzehnts, zurückgefaltet in ein einziges Dokument. Die definitorischen Erklärtexte sind größtenteils nicht nachgezogen; mehrere lehren den Implicit Flow noch immer ohne jeden Warnhinweis.

OAuth vs. OpenID Connect: Autorisierung vs. Authentifizierung

Der Satz, den alle nachsprechen – “OAuth ist keine Authentifizierung” –, verdient seine Mechanik, denn die Mechanik ist es, die eine naive Anmeldung ausnutzbar macht:

“Anmelden mit einem bloßen Access Token” scheitert, weil Access Tokens übertragbare Belege für Berechtigung sind, nicht für Anwesenheit: Eine bösartige App, die sich ein Token für eigene Zwecke besorgt hat, könnte es anderswo erneut vorlegen und den Nutzer damit imitieren. OpenID Connect existiert genau dafür, diese Lücke zu schließen – dieselben Flows, dazu eine Identitätsaussage, die kryptografisch an Ihre App gebunden ist.

Social Login: der Button auf der Mechanik

Social Login ist OIDC als UX verpackt: Der Anbieter authentifiziert, Ihre App erhält verifizierte Claims und legt ein Konto an oder ordnet es zu – kein gespeichertes Passwort, kein eigener Zurücksetzen-Ablauf, die MFA des Anbieters gratis geerbt. Die Produkt-Trade-offs verdienen ehrliche Zahlen. Versprechen von 20 bis 50 % mehr Registrierungen sind Anbieterfolklore; kontrollierte Tests haben eher 3 % gemessen, auch wenn heute rund ein Drittel der Anmeldungen im Consumer-Bereich sozial eintrifft – die Option wird offensichtlich gewollt. Was die Conversion tatsächlich bewegt: zwei oder drei Anbieter anbieten, die Ihre Zielgruppe wirklich nutzt (die Startaufstellung aus Buttons schadet messbar), immer einen E-Mail-Rückfallweg behalten und wissen, dass OAuth-Redirects innerhalb eingebetteter WebViews brechen – eine reale Ursache gescheiterter Registrierungen auf Mobilgeräten. Zwei anbieterspezifische Fakten wiegen schwer genug, um sie zu nennen: Sign in with Apple vergibt Adressen über einen privaten Relay-Dienst (…@privaterelay.appleid.com), weshalb E-Mail-basierte Verknüpfung und Verteiler mit undurchsichtigen Aliassen rechnen müssen – und die App-Store-Regeln verlangen von Apps mit Drittanbieter-Anmeldung zusätzlich eine datenschutzfreundliche Anmeldeoption.

Kontoverknüpfung und die E-Mail-Falle

Dieselbe Person wird über zwei Anbieter ankommen, und beide melden [email protected]. Die Regel, die den klassischen Fehler verhindert: Identität verankert sich an der stabilen sub-Kennung des Anbieters, niemals an der E-Mail allein. E-Mail-Adressen ändern sich, werden weitergereicht und – die scharfe Kante – sind nicht immer verifiziert: Eine 2023 beschriebene Schwachstellenklasse zeigte, dass Apps, die einem nicht verifizierten E-Mail-Claim aus den Tokens eines großen Anbieters vertrauten, für jeden zur Kontoübernahme offenstanden, der diese Adresse in seinem eigenen Anbieterkonto setzen konnte. Automatisch nur bei vom Anbieter als verifiziert bestätigten Adressen verknüpfen; sonst den Nutzer explizit zum Verknüpfen auffordern. Und planen Sie den Ausgang ein: Nutzer, die bei einem Anbieter ausgesperrt werden (das passiert ohne Vorwarnung), verlieren jede App dahinter, sofern Sie keine zweite verknüpfte Methode angeboten haben – weshalb “eine Anmeldemethode pro Nutzer” eine Support-Ticket-Maschine im Kostüm der Einfachheit ist.

Typische Anwendungsfälle

• Anmeldung in Consumer-Apps – der kanonische Fall: weniger Reibung, geerbte MFA, keine Passwortdatenbank, die auslaufen kann.
• Zugriff auf fremde APIs – der ursprüngliche OAuth-Fall: Eine Terminplanungs-App liest Ihren Kalender ohne Ihr Passwort.
• Machine-to-Machine-Authentifizierung – Client Credentials zwischen Diensten, ohne jeden Nutzer in Sicht.
• Identität über mehrere Anbieter – ein Konto, mehrere verknüpfte Anmeldemethoden, Trennung und Wiederherstellung pro Nutzer.
• Brücke zum Unternehmens-SSO – dasselbe OIDC-Muster, nur auf einen Workforce-Identity-Provider gerichtet statt auf einen sozialen.

Sollten Sie Social Login anbieten? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Sie erben die Entscheidungen des Anbieters. Zustimmungsdialoge, Sitzungsdauer, Kontowiederherstellung und Abkündigungen geschehen nach seinem Zeitplan, nicht nach Ihrem.
• Das Konzentrationsrisiko ist real. Eine Störung beim Anbieter oder ein gesperrtes Konto ist Ihr Anmeldeausfall; verknüpfte Rückfallmethoden sind die Absicherung, kein optionales Extra.
• Die Flexibilität von OAuth ist seine historische Schwäche. Ein Framework voller Optionen lädt zu unsicheren Kombinationen ein – 2.1 existiert, weil Implicit Flows, Wildcard-Redirects und Refresh Tokens ohne Rotation weiter in Produktion gingen.
• Redirect-Flows haben scharfe Kanten. state (CSRF), exakte Redirect-URIs (Open Redirect und Code-Diebstahl) und PKCE (Abfangen) sind jeweils einen vergessenen Parameter von einem Vorfall entfernt.
• Soziale Claims sind ein Boden, kein Profil. Sie bekommen Subject, E-Mail, Name – alles darüber hinaus braucht weiterhin Ihr eigenes Onboarding, und durch Privacy-Relays kann selbst die E-Mail ein Alias sein.

OAuth und Social Login mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Flows von oben falten sich in die Code-Tabs zusammen: Der Client holt die Tokens des Anbieters nativ, übergibt sie an logInWith, und die Auth-Adapter von Back4app prüfen sie serverseitig beim Anbieter, bevor der User angelegt oder zugeordnet wird – Anbieteridentitäten liegen in authData-Blöcken pro Anbieter, indiziert auf der stabilen Subject-ID, womit die Regel zur Kontoverknüpfung von Bauart her durchgesetzt ist. linkWith hängt weitere Anbieter (oder eine E-Mail-Zugangsmethode) an denselben Nutzer und löst das Aussperrproblem in einem einzigen Aufruf, und das Session-Token, das Ihre App erhält, funktioniert anschließend über die REST-, GraphQL- und Live-Query-APIs, wobei ACLs und Berechtigungen auf Klassenebene entscheiden, was es anfassen darf. Der Redirect-Tanz, die Token-Prüfung und die Sonderfälle der Verknüpfung kommen als Plattformverhalten – Sie konfigurieren die Anbieter im Dashboard und liefern den Button aus.