--- term: 'OAuth 2.0 und Social Login' seoTitle: 'OAuth 2.0 und Social Login: Flows, Tokens und PKCE' headline: 'Was sind OAuth 2.0 und Social Login?' slug: oauth-2-social-login category: auth-security shortDefinition: 'OAuth 2.0 ist ein Autorisierungsstandard, mit dem Apps auf ein Nutzerkonto bei einem anderen Dienst zugreifen – Social Login baut die Anmeldung darauf auf.' relatedTerms: - json-web-token-jwt - passwordless-authentication - identity-access-management-iam - multi-factor-authentication-mfa contrastsWith: - json-web-token-jwt aboutTerms: - 'OAuth 2.0' - 'OpenID Connect (OIDC)' - 'Social Login' - 'PKCE' faq: - question: 'Was ist OAuth 2.0, einfach erklärt?' answer: 'Ein Standard, der einer App begrenzten Zugriff auf Ihr Konto bei einem anderen Dienst verschafft, ohne dass Sie Ihr Passwort herausgeben. Statt Zugangsdaten stellt der Dienst der App ein befristetes Token mit begrenztem Scope aus – wie eine Hotelkarte, die Ihr Zimmer und den Fitnessraum öffnet, aber nicht das Büro der Direktion, und beim Auschecken verfällt.' - question: 'Ist OAuth Autorisierung oder Authentifizierung?' answer: 'Autorisierung – schon der Titel der Spezifikation sagt es, RFC 6749 heißt "The OAuth 2.0 Authorization Framework". Sie beantwortet "worauf darf diese App zugreifen?", nicht "wer ist dieser Nutzer?". Die Anmeldung über OAuth standardisiert OpenID Connect, das ein signiertes ID Token ergänzt, welches der App die Identität bestätigt.' - question: 'Was ist der Unterschied zwischen OAuth 2.0 und OpenID Connect?' answer: 'OpenID Connect ist eine dünne Identitätsschicht auf OAuth 2.0: dieselben Flows, dazu ein signiertes ID Token (ein JWT, adressiert an Ihre App, mit den Claims issuer, subject, audience und nonce) und ein userinfo-Endpoint. Jeder echte "Anmelden mit …"-Button ist OIDC oder ein herstellereigenes Äquivalent – OAuth allein definiert keinen Weg, zu beweisen, wer sich angemeldet hat.' - question: 'Welche Grant Types kennt OAuth?' answer: 'Authorization Code mit PKCE, sobald ein Nutzer beteiligt ist; Client Credentials für Machine-to-Machine; Device Authorization für Fernseher und CLIs; Refresh Token zum Erneuern des Zugriffs. Die Grants Implicit und Password sind Legacy – beide sind in OAuth 2.1 entfernt, und kein neuer Entwurf sollte sie noch verwenden.' - question: 'Was sind Access Tokens und Refresh Tokens?' answer: 'Das Access Token ist das kurzlebige Zugangsmittel, das die App der API vorlegt – mit begrenztem Scope, mit Ablaufzeit, oft ein JWT. Das Refresh Token lebt länger und wird gegen neue Access Tokens eingetauscht, ohne den Nutzer erneut zu fragen; moderne Praxis rotiert es bei jeder Verwendung, damit ein gestohlenes Token beim ersten Replay stirbt.' - question: 'Was ist PKCE und warum ist es vorgeschrieben?' answer: 'Proof Key for Code Exchange (gesprochen "pixie"): Die App startet den Flow mit dem Hash eines frischen Geheimnisses und muss beim Einlösen des Authorization Code das Original vorlegen – der Beweis, dass Einlöser und Initiator dieselbe Instanz sind. Entwickelt für mobile Apps, die kein Client Secret halten können, schützt es gegen das Abfangen des Codes – und der OAuth-2.1-Entwurf verlangt es von nahezu jedem Client.' - question: 'Was ist Social Login und wie funktioniert es?' answer: 'Es ist OIDC in einem Button: Die App leitet auf den Authorization Endpoint des Anbieters um; der Nutzer authentifiziert sich dort – das Passwort berührt die App nie – und stimmt zu; der Anbieter leitet mit einem Einmalcode zurück; die App tauscht ihn gegen Tokens und liest die stabile Subject-ID aus dem ID Token, um ein lokales Konto anzulegen oder zuzuordnen.' - question: 'Ist Social Login sicher?' answer: 'Grundsätzlich ja: Nutzer erben die gehärtete Authentifizierung und die MFA des Anbieters statt eines weiteren wiederverwendeten Passworts. Die Gegenrechnung sind das Konzentrationsrisiko – ein gesperrtes oder kompromittiertes Anbieterkonto trifft jede App dahinter – und Sorgfalt bei der Umsetzung: Apps müssen die Identität an der stabilen Subject-ID und an verifizierten Claims verankern, nie an einem rohen E-Mail-Feld.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'RFC 6749 — The OAuth 2.0 Authorization Framework' url: 'https://datatracker.ietf.org/doc/html/rfc6749' - name: 'RFC 7636 — Proof Key for Code Exchange (PKCE)' url: 'https://datatracker.ietf.org/doc/html/rfc7636' - name: 'OAuth 2.1 — consolidation draft' url: 'https://oauth.net/2.1/' - name: 'OpenID Connect Core 1.0' url: 'https://openid.net/specs/openid-connect-core-1_0.html' - name: 'OAuth — Wikipedia' url: 'https://en.wikipedia.org/wiki/OAuth' cta: title: 'Social Login ohne den Redirect-Tanz' text: 'Back4app kapselt den gesamten Flow: Übergeben Sie dem SDK die Tokens eines Anbieters, und logInWith prüft sie serverseitig, legt den Nutzer an oder ordnet ihn zu und stellt Ihre Session aus – linkWith löst die Kontoverknüpfung in einem einzigen Aufruf.' linkText: 'Kostenlos starten' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-23' translationKey: oauth-2-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](https://datatracker.ietf.org/doc/html/rfc6749) 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 | Frage | Antwort | | --- | --- | | OAuth 2.0 | Delegierte Autorisierung: Tokens mit begrenztem Scope und Ablaufzeit statt Passwörtern | | Die Verwechslung | OAuth beantwortet *worauf darf diese App zugreifen* – OIDC beantwortet *wer ist dieser Nutzer* | | Der moderne Flow | Authorization Code + PKCE – Implicit und Password Grant sind in 2.1 gestrichen | | Die Tokens | Access (kurz, begrenzter Scope) · Refresh (mit Rotation) · ID (signierte Identitäts-Claims) | | Social Login | OIDC in einem Button: Der Anbieter authentifiziert, Ihre App erhält verifizierte Claims | ## Der Authorization-Code-Flow, Schritt für Schritt Der Redirect-Tanz hinter jedem Zustimmungsdialog – mit den Parametern, auf die es ankommt: ```text 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 ``` So sieht das aus, wenn ein Backend den Ablauf kapselt – Anbieter-Tokens hinein, verifizierte Session heraus: **JavaScript:** ```javascript // 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 // 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)); ``` **Swift:** ```swift // 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) ``` **Kotlin:** ```kotlin // 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 | Rolle | Wer das ist | In "Anmelden mit …"-Begriffen | | --- | --- | --- | | Resource Owner | Der Nutzer | Sie | | Client | Die App, die Zugriff anfordert | Die App, die den Button zeigt | | Authorization Server | Stellt Codes und Tokens aus | Die Anmeldeseiten des Identity Provider | | Resource Server | Die API, die die Daten schützt | Die Profil- bzw. Nutzer-API des Anbieters | ```mermaid flowchart LR accTitle: OAuth-2.0-Authorization-Code-Flow mit PKCE accDescr: Die Client-App leitet den Nutzer mit einer PKCE-Challenge zum Authorization Server um; der Nutzer authentifiziert sich dort und stimmt zu; der Server leitet mit einem Einmalcode zurück; der Client tauscht Code plus PKCE-Verifier gegen Access, Refresh und ID Token und ruft danach den Resource Server mit dem Access Token auf. U["Nutzer
(Resource Owner)"] -->|"1 · umgeleitet mit
state + code_challenge"| AS["Authorization Server
Anmeldung + Zustimmung"] AS -->|"2 · Einmalcode"| C["Client-App"] C -->|"3 · code + code_verifier"| AS AS -->|"4 · Access · Refresh · ID Token"| C C -->|"5 · Bearer access_token"| RS["Resource Server
(API)"] ``` ## Grant Types: welcher Flow, und was OAuth 2.1 geändert hat | Grant | Wofür | Nutzer anwesend? | Status in [OAuth 2.1](https://oauth.net/2.1/) | | --- | --- | --- | --- | | Authorization Code + PKCE | Web, Mobile, SPA – alles mit einem Nutzer | Ja | **Der Standard – PKCE für nahezu alle Clients vorgeschrieben** | | Client Credentials | Machine-to-Machine, Service-Accounts | Nein | Bleibt | | Device Authorization | Fernseher, Konsolen, CLIs | Ja, auf einem zweiten Gerät | Bleibt | | Refresh Token | Zugriff unbemerkt erneuern | Nein | Bleibt – Rotation oder Sender-Constraining für öffentliche Clients Pflicht | | Implicit | Legacy-SPAs (Tokens im URL-Fragment) | Ja | **Entfernt** | | Password (ROPC) | Die App sammelt das Passwort selbst | Ja | **Entfernt** – es zerstört den gesamten Zweck | 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: | | Access Token (OAuth) | ID Token (OIDC) | | --- | --- | --- | | Adressiert an | Den Resource Server (API) | **Ihre App** (`aud` = Ihre Client-ID) | | Beweist | Dieser Inhaber darf auf diese Scopes zugreifen | Dieser Nutzer (`sub`) hat sich bei diesem Issuer (`iss`) authentifiziert, jetzt (`iat`/`exp`), für diese Anmeldung (`nonce`) | | Format | Für den Client oft undurchsichtig | Signiertes [JWT](/glossary/de/json-web-token-jwt/), das Ihre App validieren muss | | Zur Anmeldung geeignet? | **Nein** – jede vom Nutzer autorisierte App besitzt eines; es sagt nichts darüber, wer gerade anwesend ist | Ja – genau das ist seine Aufgabe | "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](https://openid.net/specs/openid-connect-core-1_0.html) 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 `ada@example.com`. 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 | Ihre Situation | Tendenz | | --- | --- | | Consumer-App, stark mobile Zielgruppe | Ja – 2 bis 3 Anbieter + E-Mail-Rückfallweg | | iOS-App mit Drittanbieter-Anmeldung | Eine datenschutzfreundliche Anmeldeoption ist Pflicht – rechnen Sie mit Relay-Adressen | | B2B- bzw. Unternehmensprodukt | OIDC ja, aber Richtung [SSO](/glossary/de/single-sign-on-sso/) im Unternehmen, nicht sozial | | Regulierte Daten, strenger Konto-Lebenszyklus | Vorsicht – Anbietersperren und Identitätsprüfung brauchen Antworten | | MVP, das diese Woche Auth braucht | Ja, über ein Backend, das die Flows kapselt | | Nutzer ohne Konten bei den großen Anbietern | E-Mail bzw. Passwortlos zuerst; Social als Option | ## 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](/glossary/de/zugriffskontrolllisten-acl/) 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.