--- title: "Was ist OAuth? Login mit Google & Apple einfach erklärt" description: "Was ist OAuth? Ich erkläre OAuth 2.0, Social Login mit Google und Apple, den Authorization Flow und warum OAuth sicherer ist als klassische Logins. Mit Flutter-Beispiel." canonical_url: "https://robocitrus.com/blog/was-ist-oauth" last_updated: "2026-07-19T00:13:22.408Z" --- "Mit Google anmelden" -- du klickst diesen Button wahrscheinlich mehrmals pro Woche. Ein Klick, du wählst dein Google-Konto aus, und schwupps bist du eingeloggt. Kein neues Passwort, kein Registrierungsformular. Aber hast du dich mal gefragt, was hinter diesem einen Klick technisch passiert? Die Antwort heißt OAuth. Und ich zeig dir, warum dieses Protokoll genial ist -- und warum es deine App sicherer macht. --- ## Kurz zusammengefasst - **OAuth 2.0** ist ein Autorisierungs-Framework, das Apps Zugriff auf Nutzerdaten gewährt, ohne Passwörter weiterzugeben - Der Flow: App leitet zu Google/Apple weiter, Nutzer loggt sich dort ein, App bekommt einen Token zurück - OAuth ist **kein** Authentifizierungsprotokoll, wird aber oft dafür genutzt (zusammen mit OpenID Connect) - Social Login (Google, Apple, Facebook) basiert auf OAuth 2.0 - Vorteile: Kein Passwort-Sharing, Token laufen ab, Berechtigungen sind einschränkbar (Scopes) --- ## Die Hotel-Schlüsselkarte Bevor es technisch wird, eine Analogie, die sofort klickt. Du checkst in einem Hotel ein. An der Rezeption zeigst du deinen Ausweis (Identitätsnachweis). Die Rezeptionistin gibt dir eine Schlüsselkarte. Diese Karte öffnet **dein** Zimmer und vielleicht den Fitnessraum. Aber nicht die Küche, nicht das Büro des Managers, nicht den Safe anderer Gäste. Die Schlüsselkarte ist **nicht** dein Ausweis. Sie beweist nicht, wer du bist. Sie gibt dir nur **begrenzten Zugang** zu bestimmten Bereichen -- für eine begrenzte Zeit. Morgen beim Checkout funktioniert sie nicht mehr. Genau so funktioniert OAuth. Deine App bekommt nicht dein Google-Passwort (den Ausweis). Sie bekommt einen Token (die Schlüsselkarte), der ihr begrenzten Zugriff auf bestimmte Daten gibt -- für eine begrenzte Zeit. ## Was ist OAuth? OAuth steht für **Open Authorization** und ist ein offenes Autorisierungs-Framework. Aktueller Standard ist **OAuth 2.0**, veröffentlicht 2012 und seitdem die Grundlage für praktisch jeden "Login mit..."-Button im Internet. **Wichtig zu verstehen:** OAuth ist ein **Autorisierungs**-Protokoll, kein **Authentifizierungs**-Protokoll. Der Unterschied: - **Authentifizierung** = Wer bist du? (Identitätsprüfung) - **Autorisierung** = Was darfst du? (Zugriffsrechte) OAuth kümmert sich um die Frage "Was darf diese App?" -- nicht um "Wer ist dieser Nutzer?". Dass OAuth trotzdem für Login genutzt wird, liegt an einer Erweiterung namens OpenID Connect (dazu gleich mehr). ## Der OAuth 2.0 Flow: Schritt für Schritt Klingt komplex, ist aber in vier Schritten erklärt: ### Schritt 1: Weiterleitung Der Nutzer klickt in deiner App auf "Mit Google anmelden". Deine App leitet ihn zu Googles Login-Seite weiter. Wichtig: Der Nutzer gibt sein Passwort **bei Google** ein, nicht in deiner App. ### Schritt 2: Einloggen & Zustimmen Der Nutzer loggt sich bei Google ein und sieht eine Zustimmungs-Seite: "Die App XY möchte auf deinen Namen und deine E-Mail-Adresse zugreifen. Erlauben?" Der Nutzer entscheidet, welche Daten er freigeben will. ### Schritt 3: Authorization Code Google leitet den Nutzer zurück zu deiner App -- mit einem kurzzeitigen Authorization Code. Dieser Code ist wie ein Abholschein: Er beweist, dass der Nutzer zugestimmt hat. ### Schritt 4: Token-Austausch Deine App schickt den Authorization Code an Google und bekommt im Gegenzug einen **Access Token** (und optional einen **Refresh Token**). Mit dem Access Token kann deine App nun auf die freigegebenen Daten zugreifen. Das Geniale: Deine App hat **zu keinem Zeitpunkt** das Passwort des Nutzers gesehen. Nicht beim Login, nicht danach, niemals. ## Die vier Rollen in OAuth OAuth definiert vier Akteure: - **Resource Owner** (du, der Nutzer): Besitzt die Daten und entscheidet, wer darauf zugreifen darf - **Client** (die App): Will auf die Daten zugreifen - **Authorization Server** (z.B. Google): Verifiziert den Nutzer und gibt Tokens aus - **Resource Server** (z.B. Googles API): Hält die tatsächlichen Daten und prüft den Token In der Praxis sind Authorization Server und Resource Server oft dasselbe System (bei Google z.B. beides Google). Aber konzeptionell sind es getrennte Rollen. ## OAuth vs. klassischer Login Warum nicht einfach E-Mail und Passwort? Hier der Vergleich:
Kriterium Klassischer Login OAuth / Social Login
Passwort-Speicherung Du musst Passwörter sicher speichern Kein Passwort bei dir gespeichert
Sicherheitsrisiko Datenleck = Passwörter kompromittiert Datenleck = Tokens ungültig machen
UX Registrierungsformular, Passwort-Regeln Ein Klick, fertig
2FA Musst du selbst implementieren Google/Apple übernehmen das
Vertrauen Nutzer muss dir vertrauen Nutzer vertraut Google/Apple
Aufwand Auth-System selbst bauen OAuth-Library einbinden
Der größte Vorteil: **Kein Passwort-Sharing.** Wenn ein Nutzer sich bei deiner App mit Google anmeldet, gibst du ihm niemals die Möglichkeit, sein Google-Passwort bei dir einzutippen. Das Passwort bleibt bei Google. Bei einem Datenleck in deiner App sind keine Passwörter betroffen. ## Social Login in deiner App [Social Login](/blog/social-login-app) ist die bekannteste Anwendung von OAuth. Die drei großen Anbieter: **Google Sign-In:** Der beliebteste Social Login. Funktioniert auf Android und iOS. Fast jeder hat ein Google-Konto. **Apple Sign-In:** Pflicht, wenn du im App Store Social Login anbietest. Besonders datenschutzfreundlich: Nutzer können ihre echte E-Mail-Adresse verstecken. **Facebook Login:** War mal der Standard, hat aber an Beliebtheit verloren. In manchen Zielgruppen (z.B. Gaming) trotzdem noch relevant. ## Code-Beispiel: Google Sign-In in Flutter So sieht Google Sign-In in einer Flutter-App aus: ```dart import 'package:google_sign_in/google_sign_in.dart'; final GoogleSignIn googleSignIn = GoogleSignIn( scopes: ['email', 'profile'], ); Future handleGoogleSignIn() async { try { final GoogleSignInAccount? account = await googleSignIn.signIn(); if (account != null) { // Authentication-Daten holen final GoogleSignInAuthentication auth = await account.authentication; print('Name: ${account.displayName}'); print('Email: ${account.email}'); print('Access Token: ${auth.accessToken}'); print('ID Token: ${auth.idToken}'); // Access Token an dein Backend senden // zur Verifikation und Session-Erstellung await sendTokenToBackend(auth.accessToken!); } } catch (error) { print('Google Sign-In fehlgeschlagen: $error'); } } Future handleSignOut() async { await googleSignIn.signOut(); print('Nutzer abgemeldet'); } ``` Das `google_sign_in`-Paket übernimmt den gesamten OAuth-Flow für dich. Du definierst die Scopes (welche Daten du willst), rufst `signIn()` auf, und bekommst den Token zurück. Den Token schickst du dann an dein Backend, das ihn bei Google verifiziert. **Wichtig:** Verifiziere den Token immer **serverseitig**. Nie nur im Client. Sonst könnte jemand einen gefälschten Token an dein Backend schicken. ## Warum OAuth sicherer ist OAuth bietet mehrere Sicherheitsvorteile gegenüber einem selbstgebauten Login-System: **Kein Passwort-Sharing:** Die App sieht das Passwort nie. Wenn deine Datenbank gehackt wird, sind keine Passwörter betroffen. **Token-Expiration:** Access Tokens laufen ab (typischerweise nach 1 Stunde). Selbst wenn ein Token gestohlen wird, ist er schnell wertlos. Dazu kommen **Scopes**, du kannst genau definieren, auf welche Daten die App zugreifen darf. Nur E-Mail? Nur Profil? Nur Lesezugriff? Scopes begrenzen den Schaden bei einem Sicherheitsproblem. **Token-Widerruf:** Nutzer können jederzeit den Zugriff widerrufen. Bei Google: Einstellungen, Sicherheit, Drittanbieter-Apps. Sofort kein Zugriff mehr. Und nicht zuletzt profitierst du von **etablierter Sicherheit**. Google, Apple und Co. investieren Milliarden in Sicherheit. 2FA, Anomalie-Erkennung, Account-Schutz -- all das bekommst du gratis, wenn du OAuth nutzt. ## OpenID Connect: OAuth + Identität Ich habe erwähnt, dass OAuth eigentlich nur für Autorisierung gedacht ist, nicht für Authentifizierung. Aber jeder nutzt es für Login. Wie passt das zusammen? Die Antwort: **OpenID Connect (OIDC)**. Das ist eine Schicht **auf** OAuth 2.0, die Identitätsinformationen hinzufügt. Konkret bekommst du neben dem Access Token auch einen **ID Token** -- ein JWT (JSON Web Token), das Informationen über den Nutzer enthält: Name, E-Mail, Profilbild. Wenn du "Login mit Google" implementierst, nutzt du in Wirklichkeit OpenID Connect, nicht reines OAuth. Der Unterschied ist für die Implementierung meistens egal (die Libraries machen alles automatisch), aber gut zu wissen. Zusammengefasst: - **OAuth 2.0** = "Diese App darf auf meine Daten zugreifen" (Autorisierung) - **OpenID Connect** = "Dieser Nutzer ist Max Mustermann" (Authentifizierung) - **In der Praxis:** Beides zusammen = Social Login ## Fazit OAuth ist das unsichtbare Rückgrat des modernen Webs. Jedes Mal, wenn du "Mit Google anmelden" klickst, läuft ein eleganter, sicherer Autorisierungs-Flow ab -- ohne dass du dein Passwort jemals preisgibst. Für deine eigene App bedeutet das: Nutze OAuth. Bau kein eigenes Login-System, wenn du Social Login anbieten kannst. Deine Nutzer bekommen eine bessere UX (ein Klick statt Registrierungsformular), und du musst keine Passwörter speichern. Win-Win. Wenn du tiefer in Social Login einsteigen willst, schau dir meinen Artikel [Social Login in Apps](/blog/social-login-app) an. Und falls du noch nicht sicher bist, [was eine API eigentlich ist](/blog/was-ist-eine-api) -- das ist die Grundlage, auf der OAuth aufbaut. ## Häufig gestellte Fragen Nein. OAuth 2.0 ist ein komplett neues Protokoll, nicht abwärtskompatibel mit OAuth 1.0. OAuth 1.0 war komplizierter (kryptografische Signaturen für jeden Request) und wird kaum noch genutzt. Wenn heute jemand von "OAuth" spricht, meint er fast immer OAuth 2.0. Social Login ist in der Regel sicherer als ein eigenes Passwort. Dein Google- oder Apple-Account ist durch 2FA, Anomalie-Erkennung und andere Sicherheitsmechanismen geschützt. Falls eine App gehackt wird, der du Zugriff gegeben hast, kannst du den Token jederzeit widerrufen, ohne dein Passwort ändern zu müssen. Nein, auf keinen Fall. Es gibt fertige Libraries und SDKs für jede Plattform: `google_sign_in` für Flutter, `@react-oauth/google` für React, Firebase Authentication als All-in-one-Lösung. Du musst den OAuth-Flow nicht von Hand bauen. Nutze die offiziellen SDKs -- die sind getestet und sicher.