Was ist OAuth? „Mit Google anmelden“ und delegierter Zugriff erklärt

OAuth ist ein offener Standard, mit dem eine Person einer App begrenzten Zugriff auf ihr Konto bei einem anderen Dienst geben kann, ohne ihr Passwort weiterzugeben. Wenn du auf „Google Kalender verbinden“ klickst und einen Bildschirm siehst, der fragt „Diese App darf deine Termine sehen?“, dann ist das OAuth. Die App erhält ein Token für genau das, was du bestätigt hast, und du kannst den Zugriff jederzeit widerrufen. Dieselbe Technik, mit einer zusätzlichen Schicht namens OpenID Connect, steckt hinter „Mit Google anmelden“ und ähnlichen Schaltflächen.

Warum OAuth beim Bauen mit KI wichtig ist

OAuth taucht beim Bau einer App in zwei typischen Situationen auf:

1. Social Login. Deine Nutzer sollen sich mit Google, Apple, Microsoft oder GitHub anmelden, statt ein weiteres Passwort anzulegen. Siehe wie du deiner App eine Anmeldung hinzufügst.
2. Zugriff auf Konten der Nutzer bei anderen Diensten. Deine App muss etwa den Kalender einer Person lesen, in ihr Social-Media-Konto posten, Dateien aus ihrem Cloud-Laufwerk holen oder ihre Buchhaltungsdaten synchronisieren.

In beiden Fällen kann dein KI-Builder den Code schreiben, aber manche Schritte kannst nur du erledigen: eine Entwickler-App beim Anbieter anlegen, eine Client-ID und ein Client Secret holen, Callback-URLs registrieren und für bestimmte Berechtigungen die Prüfung des Anbieters durchlaufen. Wenn du verstehst, wie OAuth funktioniert, werden diese Schritte und die Fehler, die dabei auftreten, deutlich weniger rätselhaft. Für das größere Bild der Anmeldung siehe was Authentifizierung ist.

Ein Alltagsvergleich

Denk an eine Hotelkarte. Beim Check-in prüft die Rezeption, wer du bist, und gibt dir dann eine Karte, die dein Zimmer und das Fitnessstudio öffnet, nicht die anderen Zimmer und nicht die Personalbereiche, und die beim Auschecken ihre Gültigkeit verliert. Die Karte enthält nicht deinen Pass. Wenn du sie verlierst, wird sie gesperrt und eine neue ausgestellt.

• Die Rezeption ist der Autorisierungsserver, also die Anmeldeseite von Google.
• Deine Ausweiskontrolle ist deine Anmeldung bei Google.
• Die Schlüsselkarte ist das Zugriffstoken.
• „Nur Zimmer und Fitnessstudio“ sind die Scopes, die du bestätigt hast.
• Das Auschecken ist der Ablauf des Tokens oder dein Widerruf.

Die App, die du nutzt, sieht dein Google-Passwort nie, nur die Schlüsselkarte.

So funktioniert OAuth Schritt für Schritt

Der häufigste Ablauf für Web-Apps ist der Autorisierungscode-Flow. So läuft es ab, wenn eine Person ihren Google Kalender mit einer Terminplanungs-App verbindet:

1. Klick. Die Person klickt auf „Google Kalender verbinden“.
2. Weiterleitung zum Anbieter. Die App schickt den Browser zu Google, mit ihrer Client-ID, den gewünschten Scopes (Kalendertermine lesen) und der Redirect-URI, an die Google die Person zurückschicken soll.
3. Anmelden und zustimmen. Die Person meldet sich bei Google an, falls nötig, und sieht einen Zustimmungsbildschirm mit den angefragten Berechtigungen. Sie klickt auf Erlauben.
4. Zurück mit einem Code. Google leitet den Browser an die Redirect-URI der App zurück, mit einem kurzlebigen, einmal gültigen Autorisierungscode.
5. Auf dem Server gegen Token tauschen. Der Server der App schickt diesen Code zusammen mit dem Client Secret direkt an Google und erhält ein Zugriffstoken (und oft ein Refresh-Token).
6. API nutzen. Der Server ruft mit dem Zugriffstoken die API von Google Kalender auf und erhält die Termine der Person.

Der Callback in Schritt 4 sieht ungefähr so aus:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

Und die Token-Antwort in Schritt 5 ist JSON wie dieses:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

Der wichtige Designpunkt: Der Tausch des Tokens läuft Server-zu-Server ab, daher müssen Client Secret und Tokens nie durch den Browser laufen.

OAuth vs. OpenID Connect vs. eigene Anmeldung

Viele Apps kombinieren diese Verfahren: Anmeldung mit E-Mail und Passwort, dazu „Mit Google anmelden“ über OIDC und getrennte OAuth-Verbindungen zu anderen Diensten.

Wichtige Begriffe

Häufige Missverständnisse

• „OAuth ist ein Anmeldesystem.“ Reines OAuth erteilt Zugriff. Die Identität übernimmt OpenID Connect. Ein bloßes Zugriffstoken als Beweis dafür zu verwenden, wer jemand ist, hat schon echte Sicherheitslücken verursacht.
• „Die App bekommt mein Passwort.“ Das passiert nie. Genau darum geht es.
• „Mehr Scopes anzufragen ist harmlos.“ Nutzer sind bei breiten Anfragen misstrauischer, und Anbieter wie Google können für sensible oder eingeschränkte Scopes eine App-Prüfung verlangen. Frag nur an, was du brauchst.
• „Das Client Secret darf ins Frontend.“ Alles im Browser-Code ist öffentlich. Halte es in serverseitigen Geheimnissen.
• „Es funktioniert beim Testen, also auch in der Produktion.“ Anbieter beschränken nicht verifizierte Apps oft, etwa auf eingetragene Testnutzer. Die Redirect-URI für deine Live-Domain muss zudem separat registriert werden.
• „Token laufen nie ab.“ Zugriffstoken verfallen schnell, und Nutzer können den Zugriff widerrufen. Deine App muss beides sauber behandeln.

Was du deinen KI-Builder fragen solltest

• „Füge „Mit Google anmelden“ über OpenID Connect mit einer gepflegten Auth-Bibliothek hinzu. Baue den OAuth-Ablauf nicht selbst.“
• „Verwende den Autorisierungscode-Flow mit PKCE und prüfe den Parameter state.“
• „Lies Client-ID und Client Secret auf dem Server aus Umgebungsvariablen.“
• „Fordere nur die Scopes an, die wir brauchen: nur Lesezugriff auf den Kalender.“
• „Nenne mir jede Redirect-URL, die ich in der Konsole des Anbieters eintragen muss: für die Vorschau, die veröffentlichte URL und meine eigene Domain.“
• „Speichere Refresh-Token verschlüsselt in der Datenbank, und wenn ein Token abgelaufen oder widerrufen ist, bitte die Person, die Verbindung neu herzustellen.“
• „Lass Nutzer die Integration in ihren Einstellungen trennen.“

OAuth und Mythex

Mythex hat keine eingebaute Endnutzer-Anmeldung für die Apps, die du baust. Die Dokumentation beschreibt einen Ansatz mit eigenem Anbieter: Du wählst eine Auth-Bibliothek oder einen gehosteten Anbieter, legst die Schlüssel als Projekt-Geheimnisse ab, und der Agent schreibt den Code. Das Rezept zum Hinzufügen einer Authentifizierung enthält einen Start-Prompt dafür. OAuth begegnet dir auch in Mythex selbst: Du kannst dich mit Google anmelden, die Verbindung zu GitHub für die Repo-Synchronisierung nutzt GitHub-OAuth, und KI-Clients, die sich über MCP mit Mythex verbinden, durchlaufen eine OAuth-Zustimmungsseite. Mehr dazu unter was Authentifizierung ist und was Zwei-Faktor-Authentifizierung ist.

Fragen