Du bist wahrscheinlich hier, weil Google Sign-In eigentlich eine schnelle Integration sein sollte, du aber stattdessen auf einen Credentials-Screen starrst und dich fragst, warum ein App-Typ ein Client Secret liefert und ein anderer nicht. Diese Verwirrung ist normal, besonders wenn du mit Capacitor, Ionic, Electron oder einem Mix aus Web und Native entwickelst.
Der Punkt, den die meisten Guides auslassen, ist genau der, der echte Implementierungen kaputt macht: Google Client IDs sind plattformspezifisch, und Nicht-Web-App-Typen bekommen oft kein Client Secret – das ist so gewollt. Wenn du die falschen Credentials erstellst, nur um ein Secret in den Flow zu erzwingen, landest du meist bei einem kaputten OAuth-Setup, das schwerer zu debuggen ist, als es sein sollte.
Inhaltsverzeichnis
- So verbindest du deine App mit dem Google-Ökosystem
- Was ist eine Google Client ID?
- So erstellst und siehst du deine Client-ID
- Plattformspezifische Client-ID-Konfigurationen
- Deine Google API Credentials absichern
- Häufige Client-ID-Fehler beheben
So verbindest du deine App mit dem Google-Ökosystem
Viele Teams stoßen gleichzeitig auf dieses Problem. Sie benötigen Mit Google anmelden, oder sie wollen nutzergesteuerten Zugriff auf Dienste wie Drive oder Calendar, und ein API Key reicht plötzlich nicht mehr aus.
Das liegt daran, dass User Sign-in und delegierter Zugriff über OAuth laufen. Google muss einen Weg finden, um deine App, sondern nicht nur die aufgerufene API. Die entscheidende Credential ist die Google Client ID.
Bei einer Cross-Platform-Codebase wird die Verwirrung schnell größer. Du hast vielleicht ein Web-Frontend, einen Android-Shell, eine iOS-App und eventuell einen Electron-Build für Desktop. Sie teilen sich zwar Branding und Backend-Logik, sollten aber nicht alle dieselbe OAuth-Identität nutzen.
Ein praktisches OAuth-Setup reduziert sich meist auf ein paar Implementierungsfragen:
- Welchen Application Type du erstellen solltest
- Ob du ein Client Secret benötigst
- Welche Redirect URIs oder Origins exakt übereinstimmen müssen
- Wie man Mobile- und Web-Flows verbindet, ohne Credentials zu vermischen
- Warum ein Flow, der im Browser funktioniert, innerhalb eines Native Wrappers scheitert
Praktische Regel: Wenn deine App nach Berechtigungen oder dem Login fragt, denke zuerst in OAuth Client Types, nicht in API Keys.
Diese Unterscheidung spart frühzeitig Zeit. Sie verhindert auch den häufigen Fehler, einen Mobile-Login-Flow um eine Web-Credential herum aufzubauen, nur weil die Console mehr Felder anzeigt. Wenn du dies in einer Capacitor App implementierst, hilft dieser Guide zu OAuth2 in Capacitor Apps ist eine hilfreiche Ergänzung für den App-seitigen Flow.
Was ist eine Google Client ID?
Ein Google OAuth 2.0 Client ID ist die öffentliche Kennung deiner App im Google-Auth-System. Google beschreibt sie als eindeutigen Benutzernamen für eine Anwendung, wenn Access Tokens von Google-Authentifizierungspunkten angefordert werden. Zudem wird darauf hingewiesen, dass sie sich von API Keys unterscheidet, da sie in OAuth-Flows zur Verifizierung der App-Identität während des Token-Austauschs genutzt wird, wie in der OAuth-Client-Dokumentation von Google Cloud.
Das einfache mentale Modell
Betrachte Client ID Google Probleme als die deiner App öffentlicher Benutzername.
Damit teilt man Google mit: „Diese Anfrage kommt von dieser registrierten App.“ Das ist entscheidend beim Sign-in, bei der Zustimmung, beim Token-Exchange und in jedem Flow, in dem deine App im Namen eines Nutzers agiert. Die Client ID wird sowohl von deiner App als auch von den Auth-Servern von Google referenziert.
Verwirrung entsteht meist dadurch, dass diese Anmeldedaten direkt neben zwei anderen Konzepten stehen, die nicht austauschbar sind.
Client-ID identifiziert die App in OAuth.
API Key identifiziert ein Projekt für bestimmte API Aufrufe, die keine delegierte Nutzerautorisierung erfordern.
Client Secret ist das vertrauliche Gegenstück, das nur in Flows und App-Typen verwendet wird, die Secrets sicher speichern können.
Viele fehlerhafte Integrationen entstehen, wenn diese Begriffe fälschlicherweise als Variationen desselben Konzepts behandelt werden. Das sind sie aber nicht.
Wo die Google Client ID in der Praxis eingesetzt wird
Wenn du Mit Google anmelden oder One Tap, ist die Client ID der Wert, den dein Frontend nutzt, um den Authentication-Handshake zu starten. Laut Google-Dokumentation muss die App außerdem in einem eigenen Cloud-Console-Projekt registriert sein, bevor das Credential generiert werden kann, und Web-Apps benötigen konfigurierte autorisierte JavaScript-Origins oder Redirect-URIs mit vollständigem Scheme und Hostnamen.
Deshalb wirkt das Setup strenger als das bloße Generieren eines Keys. Google ermöglicht nicht einfach nur Zugriff, sondern bindet die Auth-Anfrage fest an eine bekannte App-Identität.
Für Teams, die Hybrid-Apps entwickeln, ist dies das sicherste mentale Modell:
- Nutze die Client ID, um die App zu identifizieren
- Nutze den Consent Screen, um die App dem User zu präsentieren
- Nutze den richtigen App-Typ, um zu bestimmen, ob ein Secret in den Flow gehört
Wenn du eine umfassendere Einführung dazu suchst, wie App-Identität und delegierter Zugriff zusammenhängen, ist dieser Guide zur App-Autorisierung eine gute Auffrischung.
So erstellst und siehst du deine Client-ID
Der Pfad in der Console hat sich so stark verändert, dass Entwickler oft glauben, am falschen Ort zu sein. Meistens stimmt das aber nicht. Google bietet aktuell zwei Navigationspfade für diese Credentials an: den neueren Google Auth Platform > Clients Pfad und den älteren APIs & Services > Anmeldedaten Pfad, wie in beschrieben in Googles Setup-Dokumentation.
Starte im richtigen Console-Bereich
Öffne die Google Cloud Console und wähle das Projekt aus oder erstelle eines, das die Auth-Konfiguration verwaltet. Verteile die Auth nicht auf irgendwelche Projekte. Das macht Audits und den Support später extrem mühsam.
Navigiere von dort aus zu einem dieser Orte:
- Google Auth Platform > Clients
- APIs & Services > Anmeldedaten
Wenn Ihr Team unterschiedliche Navigationslabels sieht, ist das normal. Google trennt die Identitäts-Einrichtung zunehmend von den restlichen API Anmeldedaten.
Credentials erstellen, ohne sich festzulegen
Wenn Sie einen neuen OAuth-Client erstellen, ist die wichtigste Entscheidung der Anwendungstyp. Google bittet Sie, einen spezifischen Typ auszuwählen, wie zum Beispiel Web, Android, iOS, oder Desktop. Diese Wahl ist nicht nur kosmetisch. Sie legt fest, wie die App identifiziert wird und welche Konfigurationen dafür nötig sind.
Bei einer Web-App musst du Folgendes angeben:
- Autorisierte JavaScript-Ursprünge
- Autorisierte Redirect-URIs
Diese Werte müssen exakt sein. Für Web-Credentials erwartet Google das vollständige Schema und den Hostnamen, wie zum Beispiel https://www.example.com, anstatt nur eine lose Domain.
Für mobile Plattformen sieht das anders aus. Die Android-Registrierung erfordert eine Identitätsprüfung auf Package-Ebene, während iOS eigene Plattform-IDs nutzt. Wenn du Google Auth mit einem anderen Auth-Layer kombinierst, ist dieses Capacitor Social-Login-Setup mit Supabase ein hilfreiches Beispiel dafür, wie diese Komponenten zusammenpassen.
Diese Anleitung dient als gute visuelle Referenz, wenn du die UI beim Durchklicken vergleichen möchtest:
Wo du sie später findest
Nach der Erstellung erscheint die Client ID in der Credentials-Liste des Projekts. In diesem Projektbereich können Teams zudem APIs aktivieren und sehen, wie die OAuth-Identität mit dem Consent Screen verknüpft ist. Der registrierte App-Name ist das, was Nutzer beim Permission Prompt sehen – deshalb ist ein präziser Name so wichtig.
Google hält diese Credentials auch langfristig übersichtlich. Du kannst jederzeit zum Dashboard zurückkehren, um die Client ID zu kopieren, Einstellungen zu prüfen oder das zugehörige Client Secret zu verwalten.
Der Consent-Screen ist keine reine Dekoration. Er ist Teil der Vertrauensgrenze. Nutzer sehen dort deinen App-Namen, nicht deinen internen Projektnamen.
Plattformspezifische Client-ID-Konfigurationen
Der schnellste Weg, ein Google-Login-Setup zu ruinieren, ist die Annahme, dass eine Client-ID für alle Plattformen ausreicht. Das tut sie nicht. Bei Multi-Plattform-Apps muss jede Plattform ihre eigene, eindeutige OAuth 2.0 Client-ID registrieren. Speziell für Android ist der SHA1-Fingerprint zur Inhaberschaftsverifizierung erforderlich, wie in dieser Plattform-Setup-Referenz.
Warum eine App mehrere Client-IDs braucht
beschrieben. Dein Produkt mag für den Nutzer eine einzige App sein, aber für Google sind es mehrere OAuth-Clients.
Ein Web-App, ein Android Build, ein iOS Buildund ein Desktop-App bieten nicht dieselben Sicherheitseigenschaften. Sie beweisen die Identität nicht auf die gleiche Weise, und nicht alle speichern Anmeldedaten in einer vertrauenswürdigen Umgebung. Google löst dies, indem jede Plattform ein eigenes App-Registrierungsmodell erhält.
Diese Trennung ist gute Security-Hygiene. Wenn die Credential-Konfiguration einer Plattform kompromittiert oder falsch konfiguriert wird, sind die anderen nicht automatisch davon betroffen.
Hier ist die praktische Aufteilung:
- Web nutzt eine Web-Client-ID sowie striktes Matching von Origin und Redirect-URI.
- Android nutzt eine Android-Client-ID, die an die Package-Identity und den SHA1-Fingerprint gebunden ist.
- iOS nutzt eine iOS-Client-ID, die an die Bundle-Identity der App gebunden ist.
- Desktop oder Electron verwendet oft ein installiertes oder Desktop-ähnliches OAuth-Pattern statt eines Secret-basierten Browser-Flows.
Google Client-ID-Typen im Vergleich
| Anwendungstyp | Primärer Identifikator | Client Secret vorhanden? | Hauptanwendungsfall |
|---|---|---|---|
| Web | Autorisierte JavaScript-Origins und Redirect-URIs | Meistens ja | Browser-Apps und Backend-gestütztes Web-OAuth |
| Android | Package-Identität plus SHA1-Fingerprint | Oftmals nein | Natives Android-Sign-in |
| iOS | App-Bundle-Identität | Oftmals nein | Natives iPhone- und iPad-Sign-in |
| Desktop | Identität der installierten App | Oftmals nein | Desktop-Apps, inkl. Electron-ähnlicher nativer Flows |
Das Client-Secret-Paradoxon für Mobile und Desktop
Genau hier machen viele Tutorials Fehler.
Mobile und Desktop-Entwickler gehen oft davon aus, dass jeder OAuth-Client sowohl einen Client ID als auch ein Client Secretmitbringt. Also erstellen sie Webanwendung Credentials, weil sie so in der Console überhaupt ein Secret sehen können. Der Flow wirkt dadurch vollständiger, also machen sie weiter. Später bricht die Authentifizierung auf verwirrende Weise ab.
According to dieser Erklärung zum Mobile Credential Mismatcherhalten Non-Web-App-Typen wie Android, iOS oder installierte Apps absichtlich eine Client ID, aber kein Client Secret. Google möchte kein vertrauliches Secret in Client-seitiger Software speichern, aus der Nutzer es extrahieren könnten.
Diese Design-Entscheidung ist richtig. Eine Mobile App oder ein Electron-Bundle ist kein sicherer Speicher für Secrets.
Das funktioniert: Native oder clientseitige OAuth-Flows, die für Public Clients konzipiert sind.
Was nicht funktioniert: Das Erstellen von Web-Credentials für eine Mobile App, nur um ein Secret in die Implementierung zu erzwingen.
Bei Capacitor Teams tritt dies meist in einem von zwei schlechten Mustern auf:
- Die App startet einen browserbasierten Flow über einen Web Client und versucht dann, sich wie ein Confidential Server zu verhalten.
- Die App sendet ein Client Secret aus dem gebündelten code, was den Sinn eines Secrets komplett aufhebt.
Der bessere Ansatz ist es, Mobile- und Desktop-Apps als Public Clients. Bei modernem OAuth bedeutet das meist, einen Flow zu nutzen, der nicht darauf angewiesen ist, dass ein Secret im Client verborgen bleibt. Wenn dein Backend involviert ist, halte vertrauliche Operationen dort und beschränke die native App auf das, was ein Public Client tun sollte.
Ein weiterer wichtiger Punkt betrifft das Firebase-basierte Android Sign-in. In diesem Setup wird die Web Application Client ID als OAuth Client ID des Backend-Servers verwendet, während die Android-App ihre eigene plattformspezifische Identität behält. Diese Trennung verwirrt Teams oft, da sie sowohl Web- als auch Mobile-Credentials im selben Projekt sehen und annehmen, dass eines das andere ersetzt. Das ist jedoch nicht der Fall. Sie erfüllen unterschiedliche Rollen.
Wenn du dir nur eine Regel merken willst, dann diese: Wähle den Client-Typ basierend darauf, wo code läuft, nicht basierend auf der Form der Credentials, die du gerne hättest..
Deine Google API Credentials absichern
Die meisten OAuth-Vorfälle entstehen nicht durch komplexe Angriffe. Teams leaken Credentials, konfigurieren Redirect-Settings zu weitläufig oder speichern Secrets an Orten, an denen sie von vornherein nicht sicher waren.
Googles OAuth-Leitfaden betont, dass Client IDs und Secrets als private Daten zu behandeln sind. Bei Web-Apps wird die Client ID gegen vorregistrierte Redirect URIs geprüft. Wenn die Redirect URI nicht exakt übereinstimmt, lehnt Google die Anfrage ab. Diese Origin-Bindung ist Teil des Schutzes gegen Token-Interception, wie in OAuth.coms Client Registration Guidance beschrieben..
Was du sofort absichern solltest
Wenn du nur wenige Dinge richtig machen willst, dann diese:
- Versende niemals ein Client Secret in der code App. Web-Bundles, Mobile Binaries und Electron-Packages können von Nutzern inspiziert werden.
- Registriere exakte Redirect URIs. „Fast richtig“ reicht nicht aus. Google validiert bei Web-Flows strikte Übereinstimmungen.
- Halte die Origins eng gefasst. Autorisiere keine breiten Domains, nur um Hürden beim Setup zu umgehen.
- Trenne die Plattform-Credentials. Don’t let convenience push Android, iOS, and web into one credential.
Ein Detail wird leicht übersehen: Google erlaubt es Teams, neue Secrets für eine bestehende Client ID zu generieren und alte zu deaktivieren. Das ist entscheidend, wenn ein Secret geleakt wurde oder wenn du deinen Deployment-Prozess absicherst.
Was Security-Teams wirklich tun
Teams, die keine Probleme bekommen wollen, behandeln OAuth-Credentials wie jedes andere Production-Secret.
Sie halten Web-Client-Secrets im Backend, injizieren sie über das Environment-Management und prüfen, wer Zugriff auf die Console hat. Wenn du gerade deine Release-Pipeline aufräumst, ist dieser Guide über das Management von Secrets in CI/CD-Pipelines auch für dein Auth-Setup sehr nützlich.
Zudem prüfen sie Metadaten, nicht nur Keys. Der OAuth-Consent-Screen ist direkt mit der Client-Identity verknüpft, die der User sieht. Ist der App-Name vage oder irreführend, misstrauen User dem Prompt eher oder bestätigen die falsche App.
Bei Security geht es nicht nur darum, ein Secret zu verstecken. Es geht auch darum, sicherzustellen, dass die richtige App-Identity, die Redirect-Targets und der Approval-Screen immer zusammenpassen.
Häufige Client-ID-Fehler beheben
Die meisten Google OAuth-Fehler entstehen durch eine Handvoll Setup-Fehler. Die Fehlermeldungen sind nicht immer besonders freundlich, aber das eigentliche Problem ist meist recht simpel, wenn man weiß, wo man suchen muss.
Die Fixes für die meisten Probleme
redirect_uri_mismatch
Deine App sendet eine Redirect URI, die nicht exakt mit der für diesen Web-Client registrierten URI übereinstimmt. Prüfe Scheme, Host, Path und etwaige Unterschiede am Ende. Bei Web-OAuth ist das exakte Matching Teil des Security-Modells.
invalid_client
Das bedeutet meist, dass die App die falsche Client ID, das falsche Secret für diesen Client sendet oder Credentials über Plattformen hinweg vermischt. Ein klassisches Beispiel ist ein Android- oder iOS-Flow, der versehentlich Web-Credentials an der falschen Stelle nutzt.
invalid_request
Das ist ein weit gefasster Fehler, der bei Cross-Platform-Apps oft auf fehlerhafte Auth-Parameter oder einen Flow hinweist, der nicht zum Client-Typ passt. Prüfe, ob die App versucht, ein Secret einzubinden, wo es nicht hingehört, oder ob der gewählte OAuth-Flow einen anderen Client-Typ erwartet.
Google Sign-In funktioniert im Web, schlägt aber auf Mobilgeräten fehl
Zuerst sollte der Client-Typ überprüft werden. Die häufigste Fehlerquelle für Mobile-Entwickler ist die Erstellung einer Web-Application-Client-ID, nur um ein Client Secret zu erhalten, obwohl Android- oder iOS-Typen genutzt werden sollten, die das Secret oft absichtlich weglassen, wie in dieser Analyse zum Client Secret Mismatch. Falls deine Implementierung Arbeiten zum Token-Lifecycle nach dem Sign-in umfasst, ist auch dieser Guide zur Revocation hilfreich.
Android-Sign-in schlägt nach dem Erstellen der Credentials fehl
Prüfe den SHA1-Fingerprint des Android-Clients noch einmal. Wenn die Signing-Identity nicht dem entspricht, was Google erwartet, kann die App die Inhaberschaft nicht korrekt nachweisen.
Consent Screen sieht falsch aus
Verifiziere den App-Namen und das Branding im OAuth-Setup der Console. Nutzer autorisieren das, was sie dort sehen; falsche Metadaten führen daher zu Vertrauensverlust und unnötigem Support-Aufwand.
Die praktische Reihenfolge beim Debugging ist simpel: zuerst Client-Typ prüfen, dann Redirect-Settings, dann Plattform-Identifikatoren und zuletzt, ob ein Secret überhaupt Teil des Flows sein sollte.
Wenn dein Team Capacitor oder Electron-Apps ausrollt, bleiben Auth-Bugs selten isoliert. Meist treten sie zusammen mit Release-Druck, Rollbacks und umgebungsspezifischen Fixes auf. Capgo hilft Teams dabei, gezielte Updates für App-code und Assets zu pushen, ohne auf den Store-Review zu warten. Das macht es deutlich einfacher, Login-Flows, Callback-Handling und clientseitige Auth-Probleme zu beheben, wenn sie in die Produktion rutschen.
