Ein Google OAuth Client-ID ist die öffentliche App-Kennung, die Google als String anzeigt, der endet mit .apps.googleusercontent.com. Du erstellst und verwaltest sie in der Google Cloud Console unter Google Auth Platform > Clients oder APIs & Services > Anmeldedaten. Dieser Wert teilt Google mit, welche registrierte App „Sign in with Google“ startet oder OAuth-Tokens anfordert.
Du bist wahrscheinlich hier, weil Google Sign-In eine schnelle Integration hätte sein sollen, und du stattdessen vor einem Credentials-Screen sitzt und dich fragst, warum ein App-Typ einen Client Secret liefert und ein anderer nicht. Diese Verwirrung ist normal, besonders wenn du mit Capacitor, Ionic, Electron oder einem gemischten Web- und Native-Stack entwickelst.
Der Teil, den die meisten Guides überspringen, ist genau der, der in der Praxis scheitert: Google Client-IDs sind plattformspezifisch, und nicht-Web-App-Typen erhalten in der Regel aus Design-Gründen kein Client Secret. Wenn du das falsche Credential erstellst, nur um ein Secret in den Flow zu zwingen, landest du meist bei einem kaputten OAuth-Setup, das schwerer zu debuggen ist, als es sein müsste.
Inhaltsverzeichnis
- Voraussetzung: OAuth-Consent-Screen
- So erstellst du eine OAuth 2.0 Client ID
- Wo du eine bestehende Client ID findest
- Client ID vs. Client Secret
- Was ist eine Google Client ID?
- Plattformspezifische Client-ID-Konfigurationen
- Deine Google API Credentials absichern
- Häufige Client-ID-Fehler beheben
- FAQ
Voraussetzung: OAuth-Einwilligungsbildschirm
Bevor Google die Erstellung von OAuth-Clients zulässt, muss die App für Google Auth im Projekt registriert sein. Google fordert dich dazu auf, dies zu erledigen, wenn du Google Auth Platform > Clients zum ersten Mal öffnest.
Typische Schritte:
- Öffne Google Cloud Console und wähle das Projekt aus, das die Anmeldung verwaltet.
- Gehe zu Google Auth Platform (oder APIs & Dienste > OAuth-Zustimmungsbildschirm in der älteren Navigation).
- Wähle Extern oder Intern Nutzertyp, dann App-Name, Support-E-Mail und Entwicklerkontakt ausfüllen.
- Füge die Scopes hinzu, die deine App anfordert (für die einfache Anmeldung,
emailundprofilesind üblich). - Speichern Sie die Einstellungen und folgen Sie dem Workflow der Zustimmungsbildschirmen, bis die App registriert ist.
Der Anwendungsname auf diesem Bildschirm ist es, was Nutzer im Google-Berechtigungsdialog sehen. Er sollte zur installierten App passen, nicht zu einem internen Codenamen.
So erstellen Sie eine OAuth 2.0-Client-ID
Google dokumentiert den Ablauf auf der OAuth-Clients verwalten Hilfeseite. Beide dieser Einstiegspunkte funktionieren:
- Google Auth Platform > Clients (dann CLIENT ERSTELLEN)
- APIs & Services > Anmeldedaten (dann Credentials erstellen > OAuth-Client-ID)
Wähle zuerst ein Cloud-Projekt aus oder erstelle ein neues. Streue Auth-Credentials nicht über verschiedene Projekte.
Web-Application-Client
Nutze diesen Typ für Browser-Apps und für die Web Client ID viele Mobile-SDKs als Server-Audience erwarten.
- Klicken CLIENT ERSTELLEN (oder erstelle eine OAuth-Client-ID aus Credentials).
- Wähle Webanwendung als Anwendungstyp.
- Setzen Sie autorisierten JavaScript-Origins für jeden Origin, der Ihre Sign-in-UI ausführt (Scheme, Host und Port müssen exakt übereinstimmen). Verwenden Sie
http://localhost:<port>für die lokale Entwicklung. Produktions-Origin müssen HTTPS verwenden, mit Ausnahme von localhost, gemäß den Regeln von Google. - Setzen Sie Autorisierte Redirect-URIs für jede Callback-URL, die Ihr Server oder Ihre SPA nach der Rückumleitung durch Google verwendet.
- Klicken Erstellen. Kopiere die Client-ID und speichere die Client Secret sicher. Google zeigt das Secret möglicherweise nur einmal an.
Für Capacitor-Hybrid-Apps stützt die Web-Client-ID oft die Token-Verifizierung, selbst wenn die Anmeldung über native SDKs abläuft. Siehe So meldest du dich mit Google über Capacitor an für die vollständige mobile Konfiguration.
Android-Client (Paketname und SHA-1)
Android-OAuth-Clients verknüpfen Google Sign-In mit deinem Paketnamen und SHA-1 des Signaturzertifikats.
-
Klicken CLIENT ERSTELLEN und wähle Android.
-
Gib die Paketname aus Ihrer App (zum Beispiel
com.example.app, passend zuapplicationIdin Gradle). -
Hole dir SHA-1-Zertifikatsfingerabdruck für den Keystore, der den Build signiert, den du testest:
keytool -list -v -keystore path-to-debug-or-production-keystore -alias your-key-aliasFür den Standard-Debug-Keystore gibt Google an, dass das Passwort oft
androidund der Pfad ist üblicherweise~/.android/debug.keystore. -
Füge den SHA-1 in das Formular ein und klicke auf Erstellen.
-
Android kopieren Client-ID. Google gibt in der Regel kein es nicht Client Secret für diesen Typ aus.
Wenn die App bei Google Play ist, registriere auch den Play App Signing SHA-1 aus der Play Console App-Integrität. Play signiert Releases mit einem anderen Schlüssel als deinem Upload-Keystore.
iOS-Client (Bundle-ID)
- Klicken CLIENT ERSTELLEN und wähle iOS.
- Gib die Bundle-ID aus Xcode ein (derselbe Wert wie
CFBundleIdentifierin einemInfo.plist, zum Beispielcom.example.app). - Optional hinzufügen App Store ID und Team-ID wenn Google danach fragt.
- Klicken Erstellen und kopiere die iOS- Client-ID.
Nutze diesen Client mit nativem iOS Google Sign-In oder mit @capgo/capacitor-social-login wenn du Apple- und Google-Provider für Capacitor konfigurierst.
Diese Anleitung ist eine gute visuelle Referenz, wenn du die UI beim Durchklicken vergleichen willst:
Wo du eine bestehende Client ID findest
Nach der Erstellung öffnen Google Auth Platform > Clients oder APIs & Services > Anmeldedaten. Jede Zeile listet OAuth 2.0 Client IDs nach Name und Typ auf. Öffnen Sie einen Client, um dessen Client-ID string (xxxx.apps.googleusercontent.com). Web-Clients zeigen ebenfalls Client Secret Verwaltung auf derselben Detailseite.
Der Consent-Screen ist keine Dekoration. Er ist Teil der Vertrauensgrenze. Nutzer sehen dort den Namen deiner Anwendung, nicht deinen internen Projektnamen.
Client ID vs. Client Secret
| Credentials | Wer sieht es | Typische Nutzung |
|---|---|---|
| Client-ID | Öffentlich. Sicher in Apps und Frontends einbettbar. | Identifiziert deine App bei Google in jedem OAuth-Flow. |
| Client Secret | Vertraulich. Nur für Server oder CI. | Bestätigt, dass dein Backend den Web-OAuth-Client beim Austausch von code gegen Token besitzt. |
Google klassifiziert Webanwendung Clients, die auf deinen Servern laufen, als privat Clients, die ein Secret verwenden dürfen. Android, iOSund andere installiert Clients sind öffentlich Clients. Google lässt den Secret bewusst aus, da Nutzer alles aus einem APK- oder IPA-Paket extrahieren können.
Erstelle keinen Web-Client für eine Mobile-App nur, um einen Secret zu erhalten. Diese Fehlkonfiguration führt zu invalid_client, DEVELOPER_ERROR und verwirrenden Token-Audience-Fehlern.
Was ist eine Google Client ID?
Ein Google OAuth 2.0 Client ID ist die öffentliche Kennung für deine Anwendung im Google-Auth-System. Google beschreibt sie als den eindeutigen Benutzernamen einer Anwendung bei der Anforderung von Access Tokens von Google-Auth-Endpunkten und weist darauf hin, dass sie sich von API-Keys unterscheidet, da sie in OAuth-Flows zur Verifizierung der App-Identität während des Token-Austauschs verwendet wird, wie in der OAuth-Client-Dokumentation von Google Cloud.
Stell dir die Client ID Google Probleme in deiner App öffentlichen Benutzernamen.
Es teilt Google mit, dass diese Anfrage von dieser registrierten Anwendung stammt. Das ist bei der Anmeldung, der Zustimmung, dem Token-Austausch und jedem Flow relevant, in dem deine App im Namen eines Nutzers handelt. Die Client ID wird sowohl von deiner App als auch von Googles Auth-Servern referenziert.
Das Problem ist, dass diese Credential neben zwei anderen Konzepten liegt, die nicht austauschbar sind.
Client-ID identifiziert die App in OAuth.
API Key identifiziert ein Projekt für bestimmte API-Aufrufe, die keine delegierte Benutzerautorisierung erfordern.
Client Secret ist das vertrauliche Gegenstück, das nur in Flows und App-Typen verwendet wird, die Secrets sicher aufbewahren können.
Viele kaputte Integrationen entstehen, wenn jemand diese als Varianten desselben behandelt. Das sind sie nicht.
Falls du Mit Google anmelden oder One Tap, die Client-ID ist der Wert, den dein Frontend verwendet, um den Authentifizierungs-Handshake zu starten. Die Google-Dokumentation weist außerdem darauf hin, dass die App vor der Erstellung der Anmeldedaten in einem dedizierten Cloud-Console-Projekt registriert werden muss und dass Web-Apps konfigurierte autorisierte JavaScript-Origin oder Redirect-URIs mit vollständigem Schema und Hostnamen benötigen.
Für Teams, die Hybrid-Apps entwickeln, ist das sicherste mentale Modell dieses:
- Nutze die Client-ID, um die App zu identifizieren
- Nutze den Consent Screen, um die App gegenüber dem Nutzer darzustellen
- Wähle den richtigen App-Typ, um zu entscheiden, ob ein Secret in den Flow gehört
Wenn du einen breiteren Einstieg brauchst, wie App-Identität und Delegated Access zusammenspielen, ist dieser Guide zur App-Autorisierung eine gute Auffrischung. Für OAuth2 in Capacitor End-to-End, siehe OAuth2 in Capacitor Apps.
Plattformspezifische Client-ID-Konfigurationen
Der schnellste Weg, ein Google-Login-Setup zu zerschießen, ist die Annahme, eine Client-ID könne alle Plattformen abdecken. Kann sie nicht. Bei Multi-Plattform-Apps muss jede Plattform eine eigene, eindeutige OAuth-2.0-Client-ID registrieren, und Android benötigt speziell den SHA1-Fingerprint zur Verifizierung der Inhaberschaft, wie in Googles Android-Client-Anleitung.
Für den User ist dein Produkt eine App, für Google sind es mehrere OAuth-Clients.
Ein Web-App, ein Android-Build, ein iOS-Build und für eine Desktop-App weisen nicht dieselben Sicherheitseigenschaften auf. Google löst das, indem jede Plattform ihr eigenes App-Registrierungsmodell bekommt.
Hier ist die praktische Aufteilung:
- Web verwendet eine Web-Client-ID sowie eine strikte Prüfung von Origin und Redirect-URI.
- Android verwendet eine Android-Client-ID, die an die Paketidentität und den SHA1-Fingerabdruck gebunden ist.
- iOS verwendet eine iOS-Client-ID, die an die Bundle-Identität der App gebunden ist.
- Desktop oder Electron verwendet oft ein installiertes oder Desktop-ähnliches OAuth-Muster statt eines secret-basierten Browser-Flows.
Google Client ID-Typen im Vergleich
| Anwendungstyp | Primärer Bezeichner | Stellt Client Secret bereit? | Hauptanwendungsfall |
|---|---|---|---|
| Web | Autorisierte JavaScript-Origins und Redirect-URIs | Meistens ja | Browser-Apps und Backend-gestütztes Web-OAuth |
| Android | Package-Identität plus SHA1-Fingerabdruck | Oft nein | Natives Android Sign-in |
| iOS | App-Bundle-Identität | Oft nein | Natives iPhone- und iPad-Sign-in |
| Desktop | Identität der installierten App | Oft nein | Desktop-Apps, inklusive nativer Flows im Electron-Stil |
Das Client-Secret-Paradoxon für Mobile und Desktop
Mobile- und Desktop-Entwickler erwarten oft, dass jeder OAuth-Client sowohl Client-ID und einen Client Secret. Danach erstellen sie eine Webanwendung Credential, da dies der einzige Weg ist, ein Secret in der Konsole zu sehen.
Laut den OAuth-Client-Empfehlungen von Google erhalten Nicht-Web-Anwendungstypen wie Android, iOS und installierte Apps oft bewusst eine Client-ID, aber kein Client-Secret, da Google nicht möchte, dass ein vertrauliches Secret in Client-Software eingebettet wird, aus der Nutzer es extrahieren können.
Für Capacitor-Teams zeigt sich das meist in einem von zwei schlechten Mustern:
- Die App startet einen browserbasierten Flow mit einem Web-Client und versucht dann, sich wie ein vertraulicher Server zu verhalten.
- Die App sendet ein Client Secret aus dem gebündelten code, was den Sinn eines Secrets zunichtemacht.
Der bessere Ansatz ist es, Mobile- und Desktop-Apps als öffentliche Clients. Wenn dein Backend beteiligt ist, halte vertrauliche Operationen im Backend und beschränke die Native App auf das, was ein öffentlicher Client tun sollte.
Ein weiterer subtiler Punkt ist bei der Firebase-basierten Android-Anmeldung relevant. In diesem Setup wird die Client-ID vom Typ Webanwendung dient als OAuth-Client-ID des Backend-Servers, während die Android-App ihre eigene plattformspezifische Identität beibehält. Sie erfüllen unterschiedliche Rollen.
Wenn du nur eine Regel im Kopf behältst, nimm diese: Wähle den Client-Typ, der zu dem Ort passt, an dem code läuft, nicht die Credential-Form, die du dir wünschst.
Deine Google API Credentials absichern
Die meisten OAuth-Vorfälle werden nicht durch komplexe Angriffe verursacht. Teams leaken Credentials, erweitern Redirect-Einstellungen zu stark oder legen Secrets an Orten ab, wo sie nie sicher waren.
Googles OAuth-Leitlinien behandeln Client Secrets als vertrauliche Credentials, die auf Server gehören, die du kontrollierst. Client-IDs sind öffentliche Identifikatoren, sollten aber dennoch sorgfältig registriert werden. Für Web-Apps prüft Google die Client-ID gegen vorregistrierte Redirect-URIs. Weicht die Redirect-URI nicht exakt ab, lehnt Google die Anfrage ab.
Wenn du nur ein paar Dinge richtig machen willst, dann diese:
- Versende niemals ein Client Secret in der App code. Web-Bundles, mobile Binaries und Electron-Packages sind für Nutzer einsehbar.
- Registriere exakte Redirect-URIs. „Fast richtig“ reicht nicht aus. Google prüft bei Web-Flows auf exakte Übereinstimmungen.
- Halte die Origins eng gefasst. Autorisiere keine breiten Domains, nur um die Hürden beim Setup zu umgehen.
- Trenne die Plattform-Credentials. Fasse Android, iOS und Web nicht aus Bequemlichkeit zu einem Credential zusammen.
Teams, die Ärger vermeiden, behandeln OAuth-Credentials wie jedes andere Production-Secret. Sie halten Web-Client-Secrets im Backend, injizieren sie über Environment-Management und prüfen, wer Zugriff auf die Console hat. Wenn du gerade deine Release-Pipeline aufräumst, hilft dieser Guide zu das Management von Secrets in CI/CD-Pipelines sollte auch für dein Auth-Setup in Betracht gezogen werden.
Häufige Client-ID-Fehler beheben
Die meisten Google OAuth-Fehler entstehen durch eine Handvoll Setup-Fehler. Die Fehlermeldungen sind nicht immer besonders hilfreich, aber das eigentliche Problem ist meist schnell gefunden, wenn man weiß, wonach man suchen muss.
redirect_uri_mismatch
Deine App sendet eine Redirect URI, die nicht exakt mit der für diesen Web-Client registrierten übereinstimmt. Prüfe Scheme, Host, Pfad und alle Unterschiede am Ende.
invalid_client
Das heißt meist: Die App sendet die falsche Client ID, das falsche Secret für diesen Client oder vermischt Credentials über Plattformen hinweg.
origin_mismatch (JavaScript-Flows)
Die Page Origin ist nicht aufgeführt unter autorisierten JavaScript-Origins für den Web-Client.
Mindestens eine Client ID ist erforderlich, wenn Google Sign-in aktiviert ist (Supabase, Firebase und ähnliche Dashboards)
Der Provider-Toggle ist aktiviert, aber das Web Client ID Feld ist leer oder aus dem falschen Projekt kopiert. Erstelle OAuth-Clients in der Google Cloud Console. Für Supabase gibst du die Client-IDs für Web, Android und iOS als kommagetrennte Liste ein, wobei die Web-Client-ID an erster Stelle steht, wenn du diese Plattformen bereitstellst. Konfiguriere die nativen Clients und speichere. Für Supabase plus Capacitor folge Capacitor Social-Login-Setup mit Supabase.
DEVELOPER_ERROR, Error 10, oder Sign-in funktioniert im Debug-Build, schlägt aber in Production auf Android fehl
Der Android-OAuth-Client fehlt oder das Package-Name / SHA-1- Paar stimmt nicht mit dem Keystore überein, mit dem die APK signiert wurde, die Nutzer verwenden. Füge den Fingerprint des Play App Signing-Zertifikats für Store-Builds hinzu. Stelle sicher, dass dein Plugin das Web Client ID verwendet, wo SDK eine Server-Client-ID erwartet, wie in der Capgo Social Login-Doku beschrieben..
Google Sign-In funktioniert im Web, schlägt mobil aber fehl
Prüfe zuerst den Client-Typ. Ein Web-Credential kann einen Android- oder iOS-Client für native Flows nicht ersetzen.
Consent Screen sieht falsch aus
Überprüfe den App-Namen und das Branding im OAuth-Consent-Screen der Google Cloud Console.
Die praktische Debugging-Reihenfolge ist einfach: zuerst Client-Typ prüfen, dann Redirect-Settings, dann Plattform-IDs und zuletzt, ob ein Secret überhaupt in den Flow gehört.
FAQ
Müssen die Web-Client-ID und die Android-Client-ID im selben Google Cloud-Projekt liegen?
Ja. Für Google Sign-In auf Android erstellst du den Android-Client (Paketnamen und SHA-1) und den Web-Anwendungsclient im selben Google Cloud-Projekt. Die App übergibt die Web-Client-ID als Server-Client-ID, und Google prüft, ob der Android-Client zum selben Projekt gehört. Eine Abweichung ist eine häufige Ursache für DEVELOPER_ERROR. Die Capgo Social-Login-Plugin Doku zeigt das Setup.
Was ist eine Google Client ID?
Es ist die öffentliche OAuth 2.0-ID, die Google bei der Erstellung von Anmeldedaten für deine App vergibt. Sie sieht meistens so aus: 123456789012-abcdefg.apps.googleusercontent.com. Google verwendet sie immer dann, wenn deine App „Sign in with Google“ nutzt oder Autorisierungscodes gegen Tokens austauscht.
Wo finde ich meine Google Client ID?
Öffne in der Google Cloud Console Google Auth Platform > Clients oder APIs & Services > Anmeldedaten, und öffne dann deinen OAuth 2.0 Client. Das Client-ID -Feld enthält den vollständigen String zum Kopieren.
Enthalten Android- und iOS-Clients ein Client Secret?
In der Regel nicht. Installierte Apps sind öffentliche OAuth-Clients. Ein Client-Secret nur auf einem Server verwenden, den du kontrollierst, meist mit einem Webanwendung OAuth-Client.
Warum meldet mein Backend, dass mindestens eine Client ID erforderlich ist?
Google-Sign-in ist im Dashboard aktiviert, aber es wurde keine Client-ID gespeichert. Erstellen Sie die OAuth-Clients in der Google Cloud Console und fügen Sie mindestens die Web-Client-ID in die Provider-Konfiguration ein, bevor Sie die Funktion für Benutzer aktivieren.
Wie behebe ich DEVELOPER_ERROR unter Android?
Registrieren Sie einen Android-OAuth-Client mit dem korrekten Paketnamen und der SHA-1 des Signierungsschlüssels auf dem Gerät. Wenn Sie über Google Play verteilen, fügen Sie die Play App Signing SHA-1 hinzu. Stellen Sie sicher, dass die Web-Client-ID mit dem übereinstimmt, was Ihr Auth-SDK erwartet.
Kann ich eine Client-ID auf allen Plattformen wiederverwenden?
Nein. Erstellen Sie separate OAuth-Clients für Web, Android und iOS. Capacitor-Apps konfigurieren in der Regel alle drei, auch wenn Benutzer nur ein einzelnes Produkt sehen.
Wenn Ihr Team Capacitor- oder Electron-Apps veröffentlicht, bleiben Auth-Bugs selten isoliert. Sie treten meist zusammen mit Release-Druck, Rollback-Bedarf und umgebungsspezifischen Fixes auf. Capgo hilft Teams, gezielte Updates für App code und Assets auszuliefern, ohne auf das Store-Review zu warten. Das macht es deutlich einfacher, Login-Flows, Callback-Handling und clientseitige Auth-Probleme zu beheben, wenn sie in die Produktion gelangen.
