---
term: 'Social-Auth-Adapter: OAuth-Integration in BaaS'
seoTitle: 'Social-Auth-Adapter: OAuth-Integration in BaaS erklärt'
headline: 'Was sind Social-Auth-Adapter?'
slug: social-auth-adapter
category: auth-security
shortDefinition: 'Ein Social-Auth-Adapter ist eine Backend-Komponente, die Tokens eines Identity Providers prüft und daraus einen Nutzerdatensatz und eine Session macht.'
relatedTerms:
  - oauth-2-social-login
  - single-sign-on-sso
  - identity-access-management-iam
  - json-web-token-jwt
contrastsWith:
  - oauth-2-social-login
faq:
  - question: 'Was ist ein Social-Auth-Adapter?'
    answer: 'Die Übersetzungsschicht auf Plattformseite zwischen einem Identity Provider und Ihrer Nutzertabelle. Der Client holt Tokens beim Anbieter; der Adapter prüft sie serverseitig bei genau diesem Anbieter, entnimmt die stabile Subject-ID, erstellt oder findet dann den passenden Nutzerdatensatz und stellt die eigene Session Ihrer App aus. Ein Adapter pro Anbieter, ein einheitliches Nutzer- und Session-Modell auf Ihrer Seite.'
  - question: 'Worin unterscheidet sich ein Auth-Adapter von OAuth selbst?'
    answer: 'OAuth 2.0 und OpenID Connect definieren das Protokoll auf der Leitung – Flows, Tokens, Claims. Ein Adapter ist eine Implementierungskomponente, die das Ergebnis des Protokolls verarbeitet: Er validiert die Tokens des Anbieters, ordnet sie einem lokalen Konto zu und kümmert sich um Verknüpfung und Umwandlung. OAuth selbst zu bauen heißt, Weiterleitungen, Token-Austausch und Prüfung selbst zu verantworten; ein Adapter heißt, dass die Plattform alles nach dem Eintreffen der Tokens verantwortet.'
  - question: 'Was ist authData?'
    answer: 'Der Identitätsblock pro Anbieter, der am Nutzerdatensatz gespeichert wird – für jeden verknüpften Anbieter die stabile Subject-ID und die Zugangsdaten, die der Adapter geprüft hat. Ein Nutzer, der sich über zwei Anbieter angemeldet hat, trägt zwei authData-Einträge, die auf ein Konto zeigen. Weil die Zuordnung über die Subject-ID des Anbieters läuft und nicht über die E-Mail-Adresse, ist die klassische Kontoübernahme durch wiederverwendete Adressen konstruktiv ausgeschlossen.'
  - question: 'Wie funktioniert die Kontoverknüpfung in einem BaaS?'
    answer: 'Ein Verknüpfungsaufruf hängt die geprüften Tokens eines zusätzlichen Anbieters an den aktuell angemeldeten Nutzer, statt ein neues Konto anzulegen. Der Adapter prüft das Token des neuen Anbieters genau wie bei der Anmeldung und schreibt dann einen zweiten authData-Block. Danach meldet jeder der beiden Anbieter am selben Konto an – die Standardantwort auf Nutzer, die auf verschiedenen Geräten über verschiedene Schaltflächen kommen.'
  - question: 'Kann ein anonymer Nutzer auf eine Social-Anmeldung hochgestuft werden?'
    answer: 'Ja – das ist einer der besten Kniffe des Musters. Eine Gast-Session auf Basis eines anonymen Nutzers sammelt echte Objekte an: einen Warenkorb, Einstellungen, Spielfortschritt. Einen Anbieter mit diesem Nutzer zu verknüpfen verwandelt ihn an Ort und Stelle in ein identifiziertes Konto; jedes Objekt, jede ACL und jede Relation überlebt, weil sich die ID des Nutzers nie ändert. Kein Migrationsskript, keine Datenkopie.'
  - question: 'Sieht das Backend jemals das Passwort des Nutzers beim Anbieter?'
    answer: 'Nein. Der Nutzer authentifiziert sich auf der Oberfläche des Anbieters – in dessen App oder auf dessen Webseite – und der Client erhält nur Tokens. Der Adapter sieht diese Tokens, prüft sie beim Anbieter und speichert die Subject-ID. Das ist das zentrale Versprechen von OAuth, konsequent zu Ende geführt: Ihr Backend hält kein fremdes Passwort, und ein Einbruch in Ihre Nutzertabelle legt keine Zugangsdaten beim Anbieter offen.'
  - question: 'Was passiert, wenn das Token des Anbieters abläuft?'
    answer: 'In der Regel nichts Sichtbares. Die Tokens des Anbieters werden bei Anmeldung und Verknüpfung gebraucht – sobald der Adapter sie geprüft und die Session Ihrer Plattform ausgestellt hat, lebt diese Session nach Ihren Regeln, nicht nach der Ablaufzeit des Anbieter-Tokens. Der Nutzer authentifiziert sich erst dann wieder beim Anbieter, wenn Ihre Session endet oder widerrufen wird; der Adapter prüft dann ein frisches Token, und der Zyklus beginnt von vorn.'
  - question: 'Kann man einen Anbieter hinzufügen, den die Plattform nicht unterstützt?'
    answer: 'In der Regel ja – Adaptersysteme sind meist erweiterbar. Ein eigener Adapter implementiert eine kleine Prüfschnittstelle: Aus den authData, die ein Client einreicht, bestätigt er die Identität beim ausstellenden Dienst und meldet Erfolg oder Misserfolg zurück. Damit lässt sich das Muster auf Identity Provider für Nischen, auf Brücken zu Unternehmens-SSO oder auf jeden Dienst ausweiten, der eine Identität bezeugen kann – ohne die Session-Maschinerie der Plattform anzufassen.'
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: 'Social Login als ein einziger Methodenaufruf'
  text: 'Back4app liefert Auth-Adapter für die großen Identity Provider: Übergeben Sie dem SDK die Tokens eines Anbieters, und die Plattform prüft sie serverseitig, legt den Nutzer an oder findet ihn und stellt Ihre Session aus – linkWith deckt Kontoverknüpfung und das Hochstufen von Gästen ab.'
  linkText: 'Kostenlos starten'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-29'
translationKey: social-auth-adapters-oauth
---

**Ein Social-Auth-Adapter ist eine Backend-Komponente, die Tokens eines Identity Providers prüft und daraus einen Nutzerdatensatz und eine Session macht.** Er ist das fehlende Mittelstück jeder Erklärung zum Social Login: [OAuth 2.0](/glossary/de/oauth-2-social-login/) beschreibt, wie der Client die Tokens des Anbieters erhält, aber irgendetwas auf Ihrer Seite muss diese Tokens noch prüfen, entscheiden, zu welchem Konto sie gehören, und eine Session ausstellen, der Ihre APIs vertrauen. Dieses Etwas ist der Adapter.

## Das Wichtigste in Kürze

| Frage | Antwort |
| --- | --- |
| Was es ist | Die Schicht auf Plattformseite, die geprüfte Anbieter-Tokens in Ihren Nutzer plus Session verwandelt |
| vs. rohes OAuth | OAuth ist das Protokoll; der Adapter verarbeitet dessen Ergebnis im Backend |
| Der Identitätsschlüssel | Die stabile Subject-ID des Anbieters, pro Anbieter in `authData` gespeichert |
| Die Abläufe, die er besitzt | Anmeldung, Kontoverknüpfung (`linkWith`), Hochstufen von anonym zu identifiziert |
| Was Sie nie halten | Das Anbieter-Passwort des Nutzers – nur Tokens, serverseitig geprüft |

## Der Adapter im Einsatz

Anbieter-Tokens hinein, geprüfte Session heraus – samt dem Ablauf zum Hochstufen von Gästen:

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

## Was der Adapter tatsächlich tut

Der Anteil des Clients am Social Login endet, wenn ein großer Identity Provider ihm Tokens übergibt. Der Anteil des Adapters beginnt genau dort, und er läuft vollständig serverseitig ab:

```mermaid
flowchart LR
  accTitle: Wie ein Social-Auth-Adapter Anbieter-Tokens in eine Plattform-Session verwandelt
  accDescr: Der Client authentifiziert sich bei einem Identity Provider und erhält Tokens; er reicht sie als authData beim Backend ein, wo der anbieterspezifische Adapter die Tokens direkt beim Anbieter prüft, anhand der stabilen Subject-ID einen Nutzerdatensatz findet oder anlegt und das eigene Session-Token der Plattform an den Client zurückgibt.
  C["Client-App"] -->|"1 · authentifiziert sich beim<br/>Identity Provider"| P["Identity Provider"]
  P -->|"2 · Tokens"| C
  C -->|"3 · authData"| A["Auth-Adapter<br/>(Backend)"]
  A -->|"4 · Tokens prüfen"| P
  A -->|"5 · finden oder anlegen<br/>über Subject-ID"| U[("Nutzertabelle<br/>authData-Blöcke")]
  A -->|"6 · Session-Token der Plattform"| C
```

Schritt 4 ist der, den selbst gebaute Implementierungen auf eigene Gefahr überspringen: Der Adapter ruft den Anbieter auf, um zu bestätigen, dass das Token echt, nicht abgelaufen und für diese App ausgestellt ist – eine "Prüfung" auf Client-Seite beweist nichts, denn jede Anfrage kann jede Identität behaupten. Schritt 5 kodiert die Zuordnungsregel, die die klassische Übernahme verhindert: Die Zuordnung läuft über die stabile Subject-ID des Anbieters, nie über einen E-Mail-Claim. Das Ergebnis in der Nutzertabelle ist eine `authData`-Map – ein geprüfter Block pro verknüpftem Anbieter, alle auf einen einzigen Nutzer zeigend, dessen Objekte, [ACLs](/glossary/de/zugriffskontrolllisten-acl/) und Sessions sich genau so verhalten, als hätte das Konto ein Passwort.

## Auth-Adapter vs. selbst gebautes OAuth

| Aspekt | Mit einem Adapter | Selbst gebaut |
| --- | --- | --- |
| Token-Prüfung | Die Plattform ruft den Anbieter serverseitig auf | Sie implementieren sie pro Anbieter und halten sie aktuell |
| Kontozuordnung | Konstruktionsbedingt über die stabile Subject-ID | Ihr Schema, Ihre Fehler – die Zuordnung per E-Mail ist der klassische Fehler |
| Kontoverknüpfung | Ein `linkWith`-Aufruf | Eigene Tabellen und Zusammenführungslogik |
| Hochstufen von Gästen | `linkWith` auf einem anonymen Nutzer, an Ort und Stelle | Manuelle Datenmigration zwischen Konten |
| Ausstellen der Session | Plattform-Session, über alle Anbieter hinweg einheitlich | Eigenbau auf Basis von [JWTs](/glossary/de/json-web-token-jwt/) |
| Neuer Anbieter | Konfigurieren (oder einen eigenen Adapter einhängen) | Noch eine OAuth-Client-Implementierung |

Der Satz zum Verinnerlichen: Der Adapter ersetzt OAuth nicht – der Client führt weiterhin den Flow des Anbieters aus, und PKCE bleibt wichtig. Er ersetzt alles, was Sie sonst *nach* dem Eintreffen der Tokens bauen müssten, und genau dort sitzen die meisten Schwachstellen des Social Login tatsächlich.

## Verknüpfen und das Hochstufen, das Ihr Onboarding rettet

Zwei Abläufe unterscheiden adapterbasierte Auth von einem bloßen Endpoint, der "ein Token prüft". **Kontoverknüpfung**: Dieselbe Person kommt über verschiedene Schaltflächen – der Verknüpfungsaufruf hängt den geprüften Block eines zweiten Anbieters an den angemeldeten Nutzer, sodass beide Anbieter dasselbe Konto erreichen und eine Aussperrung beim Anbieter nicht länger einen verlorenen Kunden bedeutet. **Hochstufen anonymer Nutzer**: Apps, die Gäste sofort handeln lassen, unterlegen den Gast mit einem anonymen Nutzer; meldet sich dieser schließlich an, wandelt die Verknüpfung den Nutzer an Ort und Stelle um – dieselbe Objekt-ID, also überleben Warenkorb, Fortschritt und Berechtigungen pro Objekt. Teams, die die Registrierung auf diese Weise hinauszögern, entfernen ihren reibungsreichsten Bildschirm, ohne dass am Ende ein Migrationsskript wartet. Derselbe Mechanismus läuft rückwärts als Aufheben der Verknüpfung – so mustern Nutzer einen Anbieter aus, ohne das Konto zu verlieren, und [Single-Sign-On](/glossary/de/single-sign-on-sso/)-Installationen nutzen es, wenn Identitäten unter einem Unternehmensanbieter zusammengeführt werden.

## Typische Anwendungsfälle

- **Anmeldung von Endnutzern bei großen Identity Providern** – die üblichen Schaltflächen, mit Prüfung, Zuordnung und Sessions einmal und einheitlich erledigt.
- **Onboarding zuerst als Gast** – anonyme Nutzer werden im Moment der Entscheidung an Ort und Stelle hochgestuft, ohne Datenverlust.
- **Konten mit mehreren Anbietern** – ein Nutzer, mehrere verknüpfte Anmeldewege, Verknüpfung pro Nutzer lösbar; die Antwort auf Aussperrungen beim Anbieter.
- **Brücken zu Unternehmensidentitäten** – ein eigener Adapter, der auf ein [IAM](/glossary/de/iam/)-System des Unternehmens statt auf einen sozialen Anbieter zeigt.
- **Kontinuität über Geräte hinweg** – die Plattform-Session funktioniert über REST, GraphQL und Live Queries hinweg, unabhängig davon, welcher Anbieter sie geöffnet hat.

## Auth-Adapter verwenden oder den Flow selbst bauen? Entscheidungsmatrix

| Ihre Situation | Tendenz |
| --- | --- |
| Übliche Anbieter, übliche Abläufe | Adapter – das ist der Standardweg |
| Sie brauchen eine eigene Verarbeitung von Claims mitten im Flow | Selbst gebaut oder ein eigener Adapter, wenn die Plattform es zulässt |
| Kleines Team, Auth ist nicht Ihr Produkt | Adapter – Fehler in der Token-Prüfung sind Material für einen Einbruch |
| Sie betreiben bereits einen Identitätsdienst | Binden Sie ihn über einen eigenen Adapter an, statt ihn zu duplizieren |
| Die Compliance verlangt Hoheit über jedes Auth-Byte | Selbst gebaut auf Open-Source-Komponenten, die Sie prüfen können |
| Gäste müssen ohne Datenverlust umgewandelt werden | Adapter – die Verknüpfung an Ort und Stelle ist genau dieses Feature |

## Grenzen und Trade-offs

- **Sie erben die Anbieterliste der Plattform.** Die verbreiteten Anbieter sind abgedeckt; ein Nischenanbieter bedeutet, einen eigenen Adapter zu schreiben oder auf die Roadmap zu warten.
- **Der Ablauf auf der Client-Seite bleibt Ihrer.** Der Adapter setzt beim Einreichen der Tokens an – native Anmelde-UX, Weiterleitungen und PKCE bleiben Client-Arbeit, und Einschränkungen von WebViews in Apps bereiten weiterhin Probleme.
- **Die Politik des Anbieters schlägt durch.** Zustimmungsdialoge, Token-Formate, weiterleitende E-Mail-Adressen und Abkündigungen ändern sich nach dem Zeitplan des Anbieters; der Adapter nimmt die Mechanik ab, nicht die Politik.
- **Die Fehlersuche erstreckt sich über drei Parteien.** Eine fehlgeschlagene Anmeldung kann im Client-Ablauf, im Prüfaufruf des Adapters oder beim Anbieter entstehen – gute Logs an der Adaptergrenze lohnen sich vom ersten Tag an.
- **Einheitlichkeit ist ein zweischneidiges Schwert.** Der Adapter normalisiert jeden Anbieter auf Subject-ID plus Profil; braucht Ihre App tiefe anbieterspezifische Daten, werden Sie die APIs dieses Anbieters ohnehin gesondert aufrufen.

## Social-Auth-Adapter 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. Seine Auth-Adapter setzen alles aus diesem Artikel als [Verhalten der Plattform](https://docs.parseplatform.org/parse-server/guide/#oauth-and-3rd-party-authentication) um: `logInWith` prüft Anbieter-Tokens serverseitig und legt den Nutzer anhand der stabilen Subject-ID an oder findet ihn, `linkWith` erledigt sowohl die Kontoverknüpfung als auch das Hochstufen anonymer Nutzer an Ort und Stelle, und die entstehende Session funktioniert über jede API hinweg, wobei CLPs und ACLs entscheiden, worauf sie zugreifen darf. Anbieter werden im Dashboard konfiguriert, und die Adapterschnittstelle ist offen – ein eigener Anbieter ist ein kleines Prüfmodul, kein Fork Ihres Auth-Stacks.