Titelbild: KI-generiert

Was ist OAuth? Login mit Google & Apple einfach erklärt

Veröffentlicht:18. März 2026

1 min Lesezeit

"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.

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 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.

So sieht Google Sign-In in einer Flutter-App aus:

import 'package:google_sign_in/google_sign_in.dart';

final GoogleSignIn googleSignIn = GoogleSignIn(
  scopes: ['email', 'profile'],
);

Future<void> 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<void> 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 an. Und falls du noch nicht sicher bist, was eine API eigentlich ist -- das ist die Grundlage, auf der OAuth aufbaut.