Un Identifiant client Google OAuth is the public app identifier Google shows as a string ending in .apps.googleusercontent.com. Vous le créez et le gérez dans Console Google Cloud sous Google Auth Platform > Clients ou API et services > Identifiants. Cette valeur indique à Google quelle application enregistrée lance le flux Sign in with Google ou demande des tokens OAuth.
Vous êtes probablement ici parce que Google Sign-In aurait dû être une intégration rapide, et vous voilà devant un écran d'identifiants à vous demander pourquoi un type d'application vous donne un client secret et pas un autre. Cette confusion est normale, surtout si vous développez avec Capacitor, Ionic, Electron ou une stack mixte web et native.
L'étape que la plupart des guides ignorent est celle qui casse les implémentations réelles : Les client ID Google sont propres à chaque plateforme, et souvent, les types d'applications non-web ne reçoivent pas de client secret, par conception. Si vous créez le mauvais identifiant juste pour forcer un secret dans le flux, vous vous retrouvez généralement avec une configuration OAuth cassée, plus difficile à déboguer qu'elle ne devrait l'être.
Table des matières
- Prérequis : écran de consentement OAuth
- Comment créer un client ID OAuth 2.0
- Où trouver un client ID existant
- Client ID vs client secret
- Qu'est-ce qu'un client ID Google ?
- Configurations du client ID selon la plateforme
- Sécuriser vos identifiants Google API
- Dépanner les erreurs courantes de Client ID
- FAQ
Prérequis : écran de consentement OAuth
Avant de pouvoir créer des clients OAuth, le projet doit enregistrer l’application pour Google Auth. Google vous invite à compléter cette étape lorsque vous ouvrez Google Auth Platform > Clients pour la première fois.
Étapes typiques :
- Ouvrez Console Google Cloud et sélectionnez le projet qui gérera la connexion.
- Accéder à Plateforme d’authentification Google (ou API et services > Écran de consentement OAuth dans l’ancienne navigation).
- Choisissez Externe ou Interne type d’utilisateur, puis renseignez le nom de l’application, l’e-mail de support et le contact développeur.
- Ajoutez les scopes que votre application demandera (pour une connexion de base,
emailetprofilesont courants). - Enregistrez et poursuivez le workflow de l'écran de consentement jusqu'à ce que l'application soit enregistrée.
Le nom de l'application sur cet écran est celui que les utilisateurs voient sur le prompt d'autorisation Google. Il doit correspondre à l'application qu'ils ont installée, et non à un nom de code interne.
Comment créer un client ID OAuth 2.0
Google documente le flux sur la Gérer les clients OAuth page d'aide. Ces deux points d'entrée fonctionnent :
- Google Auth Platform > Clients (puis Créer un client)
- API et services > Identifiants (puis Créer des identifiants > ID client OAuth)
Sélectionnez ou créez d’abord un projet Cloud. Ne dispersez pas les identifiants d’authentification dans des projets sans rapport.
Client d'application web
Utilisez ce type pour les applications web et pour le ID client Web nombreux SDK mobiles attendent comme audience serveur.
- Cliquez Créer un client (ou créez un identifiant client OAuth à partir de Credentials).
- Choisissez Application web en tant que type d’application.
- Définissez Origines JavaScript autorisées à chaque origine qui exécute votre interface de connexion (le schéma, l’hôte et le port doivent correspondre exactement). Utilisez
http://localhost:<port>pour le développement local. Les origines de production doivent utiliser HTTPS, à l’exception de localhost, conformément aux règles de Google. - Définissez URI de redirection autorisées à chaque URL de callback utilisée par votre serveur ou votre SPA après la redirection de Google.
- Cliquez Créer. Copiez le ID client et stockez le Secret client en lieu sûr. Google peut n’afficher le secret qu’une seule fois.
Pour les apps hybrides Capacitor, l’ID client Web sert souvent à la vérification des tokens, même si la connexion passe par des SDK natifs. Voir Comment se connecter avec Google à l’aide de Capacitor pour l’intégration mobile complète.
Client Android (nom du package et SHA-1)
Les clients OAuth Android associent Google Sign-In à votre nom du package et le SHA-1 du certificat de signature.
-
Cliquez Créer un client et choisissez Android.
-
Saisissez le Nom du package de votre application (par exemple
com.example.app, correspondant àapplicationIddans Gradle). -
Récupérez Empreinte du certificat SHA-1 pour le keystore qui signe le build que vous testez :
keytool -list -v -keystore path-to-debug-or-production-keystore -alias your-key-aliasPour le keystore de debug par défaut, Google indique que le mot de passe est souvent
androidet le chemin est généralement~/.android/debug.keystore. -
Collez le SHA-1 dans le formulaire et cliquez sur Créer.
-
Copier Android ID client. Google fournit généralement pas un secret client pour ce type.
Si l'app est sur Google Play, enregistrez également le Play App Signing SHA-1 depuis Play Console Intégrité de l’application. Play re-signe les releases avec une clé différente de votre keystore d’upload.
Client iOS (bundle ID)
- Cliquez Créer un client et choisissez iOS.
- Saisissez le ID du bundle depuis Xcode (la même valeur que
CFBundleIdentifierdansInfo.plist, par exemplecom.example.app). - Ajouter (facultatif) ID de l'App Store et ID d'équipe lorsque Google les demande.
- Cliquez Créer et copiez l’iOS ID client.
Utilisez ce client avec la connexion Google native iOS ou avec @capgo/capacitor-social-login lors de la configuration des fournisseurs Apple et Google pour Capacitor.
Ce tutoriel vidéo est une bonne référence visuelle si vous souhaitez comparer l’interface pendant que vous naviguez :
Où trouver un client ID existant
Après la création, ouvrez Google Auth Platform > Clients ou API et services > Identifiants. Chaque ligne répertorie les identifiants de client OAuth 2.0 par nom et type. Ouvrez un client pour copier son ID client chaîne (xxxx.apps.googleusercontent.com). Les clients Web affichent également Secret client la gestion sur la même page de détails.
L’écran de consentement n’est pas un simple habillage. Il fait partie de la frontière de confiance. Les utilisateurs y voient le nom de votre application, pas le surnom interne de votre projet.
Identifiant de client vs secret de client
| Identifiant | Qui le voit | Usage typique |
|---|---|---|
| ID client | Public. Sans risque d’intégration dans les apps et les frontends. | Identifie votre app auprès de Google dans chaque flux OAuth. |
| Secret client | Confidentiel. Côté serveur ou CI uniquement. | Prouve que votre backend possède le client Web OAuth lors de l'échange code-for-token. |
Google classe Application web les clients qui tournent sur vos serveurs comme privé des clients pouvant utiliser un secret. Android, iOS, et d'autres installé les clients sont publics clients. Google omet volontairement le secret, car les utilisateurs peuvent extraire tout ce qui est embarqué dans un APK ou un IPA.
Ne créez pas de client Web pour une application mobile juste pour obtenir un secret. Cette incohérence provoque invalid_client, DEVELOPER_ERROR, et des erreurs de token audience déroutantes par la suite.
Qu'est-ce qu'un client ID Google ?
Un ID client Google OAuth 2.0 est l'identifiant public de votre application dans le système d'authentification de Google. Google le décrit comme le nom d'utilisateur unique d'une application lors de la demande de tokens d'accès auprès des endpoints d'authentification Google, et précise qu'il est distinct des clés API car il est utilisé dans les flux OAuth pour vérifier l'identité de l'app lors de l'échange de tokens, comme expliqué dans la documentation du client OAuth de Google Cloud.
Pensez aux problèmes de client ID Google comme ceux de votre app nom d'utilisateur public.
Il indique à Google : « cette requête provient de cette application enregistrée ». C'est essentiel lors de la connexion, du consentement, de l'échange de token et de tout flux où votre application demande d'agir au nom d'un utilisateur. L'identifiant client est destiné à être référencé par votre application et par les serveurs d'authentification de Google.
Ce qui pose problème, c’est que cette référence se trouve à côté de deux autres concepts qui ne sont pas interchangeables.
ID client identifie l'application dans OAuth.
clé API identifie un projet pour certains appels API qui n'impliquent pas d'autorisation déléguée d'utilisateur.
Secret client est l'équivalent confidentiel utilisé uniquement dans les flux et types d'app qui peuvent conserver des secrets en toute sécurité.
Beaucoup d'intégrations cassées commencent quand on traite ces éléments comme des variantes d'une même chose. Ce n'est pas le cas.
Si vous avez besoin Connexion avec Google ou One Tap, l'identifiant client est la valeur que votre frontend utilise pour initier la poignée de main d'authentification. La documentation de Google précise aussi que l'app doit être enregistrée dans un projet Cloud Console dédié avant de pouvoir générer l'identifiant, et que les apps web exigent des origines JavaScript autorisées ou des URI de redirection configurées avec le schéma et le nom d'hôte complets.
For teams building hybrid apps, the safest mental model is this:
- Utiliser l'identifiant client pour identifier l'app
- Utiliser l'écran de consentement pour présenter l'app à l'utilisateur
- Utiliser le bon type d'app pour déterminer si un secret a sa place dans le flux
Pour une introduction plus large à l’articulation entre identité d’application et accès délégué, ce guide sur l’autorisation d’applications est un bon rappel. Pour OAuth2 de bout en bout dans Capacitor, consultez OAuth2 dans les apps Capacitor.
Configurations du client ID selon la plateforme
Le moyen le plus rapide de casser une configuration de connexion Google est de supposer qu'un seul client ID peut couvrir toutes les plateformes. C'est faux. Pour les apps multiplateformes, chaque plateforme doit enregistrer son propre client ID OAuth 2.0 distinct, et la configuration Android exige spécifiquement l'empreinte SHA1 pour vérifier la propriété, comme indiqué dans les instructions de Google pour Android.
Votre produit peut être une seule app aux yeux de l'utilisateur, mais il représente plusieurs clients OAuth pour Google.
Un application web, un Un build Android, un build iOS, et une application desktop ne présentent pas les mêmes propriétés de sécurité. Google gère cela en attribuant à chaque plateforme son propre modèle d’enregistrement d’application.
Voici la répartition pratique à suivre :
- Le Web utilise un client ID web et une correspondance stricte de l'origine et de l'URI de redirection.
- Android utilise un client ID Android lié à l’identité du package et à l’empreinte SHA1.
- iOS utilise un identifiant client iOS lié à l’identité du bundle de l’application.
- Bureau ou Electron utilise souvent un flux OAuth de type bureau ou installé, plutôt qu'un flux navigateur basé sur un secret.
Comparatif des types de client ID Google
| Type d'application | Identifiant principal | Fournit un client secret ? | Cas d'usage principal |
|---|---|---|---|
| Le Web | Origines JavaScript autorisées et URI de redirection | Généralement oui | Applications web et OAuth web assisté par le backend |
| Android | Identité du package et empreinte SHA1 | Souvent non | Connexion native Android |
| iOS | Identité du bundle de l'app | Souvent non | Connexion native sur iPhone et iPad |
| Ordinateur | Identité de l'app installée | Souvent non | Applications desktop, incluant les flux natifs de type Electron |
Le paradoxe du client secret sur mobile et desktop
Les développeurs mobile et desktop s'attendent souvent à ce que chaque client OAuth soit fourni avec un ID client et une secret client. Ensuite, ils créent un Application web credential, car c’est la seule façon de voir un secret dans la console.
Selon les recommandations de Google pour les clients OAuth, les types d’applications non web comme Android, iOS et les applications installées reçoivent souvent volontairement un client ID mais aucun client secret, car Google ne veut pas qu’un secret confidentiel soit intégré dans un logiciel côté client, où les utilisateurs peuvent l’extraire.
Pour les équipes Capacitor, cela se manifeste généralement par l'un de ces deux mauvais patterns :
- L'application lance un flux basé sur un navigateur en utilisant un client web puis tente de se comporter comme un serveur confidentiel.
- L'application envoie un secret client à partir de code intégré au bundle, ce qui annule l’intérêt d’avoir un secret.
La meilleure approche consiste à considérer les applications mobiles et de bureau comme clients publics. Si votre backend est impliqué, gardez les opérations confidentielles côté backend et limitez l’application native à ce qu’un client public doit faire.
Un autre point subtil concerne la connexion Android basée sur Firebase. Dans cette configuration, le client ID de type application web est utilisé comme client ID OAuth du serveur backend, tandis que l’application Android conserve son identité propre à la plateforme. Ils jouent des rôles distincts.
If you remember one rule, use this one: choisissez le type de client correspondant à l’endroit où s’exécute code, pas à la forme de credential que vous auriez aimé avoir.
Sécuriser vos identifiants Google API
La plupart des incidents OAuth ne viennent pas d’attaques complexes. Les équipes laissent fuiter des credentials, élargissent à l’excès les paramètres de redirection ou placent des secrets là où ils n’auraient jamais dû être.
Les recommandations OAuth de Google considèrent les secrets de client comme des credentials confidentiels qui doivent résider sur des serveurs que vous contrôlez. Client IDs sont des identifiants publics, mais vous devez quand même les enregistrer avec soin. Pour les applications web, Google vérifie l’identifiant client par rapport aux URI de redirection pré-enregistrées. Si l’URI de redirection ne correspond pas exactement, Google refuse la requête.
Si vous ne faites que quelques choses bien, faites celles-ci :
- Ne déployez jamais un client secret dans une app code. Les bundles web, les binaires mobiles et les paquets Electron sont inspectables par les utilisateurs.
- Enregistrez les URI de redirection exactes. Presque, ce n’est pas assez. Google valide les correspondances strictes pour les flux web.
- Restreignez les origines. N’autorisez pas de domaines trop larges juste pour éviter les frictions de configuration.
- Séparez les identifiants par plateforme. Ne laissez pas la commodité regrouper Android, iOS et web dans un seul identifiant.
Les équipes qui évitent les ennuis traitent les identifiants OAuth comme n'importe quel autre secret de production. Elles gardent les secrets de client web côté backend, les injectent via la gestion des environnements et auditent qui a accès à la console. Si vous nettoyez votre pipeline de release, ce guide sur la gestion des secrets dans les pipelines CI/CD mérite aussi d'être appliqué à votre configuration d'auth.
Dépanner les erreurs courantes de Client ID
La plupart des échecs Google OAuth viennent d'un petit nombre d'erreurs de configuration. Le message d'erreur n'est pas toujours très parlant, mais le problème sous-jacent est généralement simple une fois qu'on sait où chercher.
redirect_uri_mismatch
Votre application envoie une URI de redirection qui ne correspond pas exactement à celle enregistrée pour ce client web. Vérifiez le schéma, l'hôte, le chemin et toute différence en fin d'URL.
invalid_client
Cela signifie généralement que l'application envoie le mauvais client ID, le mauvais secret pour ce client, ou qu'elle mélange les identifiants entre les plateformes.
origin_mismatch (Flux JavaScript)
L'origine de la page n'est pas répertoriée sous Origines JavaScript autorisées pour le client Web.
Au moins un client ID est requis lorsque la connexion Google est activée (dashboards Supabase, Firebase et similaires)
Le bascule du fournisseur est activée mais le ID client Web champ est vide ou collé depuis le mauvais projet. Créez des clients OAuth dans Google Cloud Console. Pour Supabase, saisissez les identifiants de client Web, Android et iOS sous forme de liste séparée par des virgules, en plaçant l'identifiant Web en premier, lorsque vous déployez ces plateformes. Configurez les clients natifs, puis enregistrez. Pour Supabase plus Capacitor, suivez la configuration du social login Capacitor avec Supabase.
DEVELOPER_ERROR, erreur 10, ou la connexion fonctionne en debug mais échoue en production sur Android
Le client OAuth Android est manquant ou la paire nom de package / SHA-1 ne correspond pas au keystore qui a signé l'APK utilisé par les utilisateurs. Ajoutez l'empreinte du certificat Play App Signing pour les builds destinés aux stores. Vérifiez que votre plugin utilise le ID client Web où SDK attend un client ID serveur, comme décrit dans la documentation Social Login de Capgo.
Google Sign-In fonctionne sur le web mais échoue sur mobile
Inspectez d'abord le type de client. Un identifiant web ne peut pas remplacer un client Android ou iOS pour les flux natifs.
L'écran de consentement semble incorrect
Vérifiez le nom de l'application et le branding sur l'écran de consentement OAuth dans la Google Cloud Console.
L'ordre de débogage pratique est simple : vérifiez d'abord le type de client, puis les paramètres de redirection, puis les identifiants de plateforme, et enfin si un secret doit figurer dans le flux.
FAQ
Le client ID Web et le client ID Android doivent-ils être dans le même projet Google Cloud ?
Oui. Pour Google Sign-In sur Android, créez le client Android (nom du package et SHA-1) et le client d'application Web dans le même projet Google Cloud. L'application transmet le client ID Web comme client ID serveur, et Google vérifie que le client Android appartient au même projet. Une incohérence est une cause fréquente de DEVELOPER_ERROR. La documentation du plugin de social login Capgo montre la configuration.
Qu'est-ce qu'un client ID Google ?
C'est l'identifiant OAuth 2.0 public que Google attribue lorsque vous créez des identifiants pour votre application. Il ressemble généralement à 123456789012-abcdefg.apps.googleusercontent.com. Google l’utilise à chaque démarrage de votre application, lors de la connexion avec Google ou de l’échange de codes d’autorisation contre des tokens.
Où trouver mon identifiant client Google ?
Dans Google Cloud Console, ouvrez Google Auth Platform > Clients ou API et services > Identifiants, puis ouvrez votre client OAuth 2.0. Le ID client le champ contient la chaîne complète à copier.
Les clients Android et iOS incluent-ils un client secret ?
Généralement non. Les applications installées sont des clients OAuth publics. N'utilisez un client secret que sur un serveur que vous contrôlez, généralement avec un Application web client OAuth.
Pourquoi mon backend indique-t-il qu'au moins un client id est requis ?
La connexion Google est activée dans le dashboard, mais aucun client ID n'est enregistré. Créez les clients OAuth dans Google Cloud Console et collez au moins le client ID Web dans la configuration du fournisseur avant d'activer la fonctionnalité pour les utilisateurs.
Comment corriger DEVELOPER_ERROR sur Android ?
Enregistrez un client OAuth Android avec le nom de package correct et le SHA-1 de la clé de signature sur l'appareil. Si vous distribuez via Google Play, incluez le SHA-1 de Play App Signing. Alignez le client ID Web sur ce que votre auth SDK attend.
Puis-je réutiliser un seul client ID sur toutes les plateformes ?
Non. Créez des clients OAuth distincts pour Web, Android et iOS. Les applications Capacitor configurent souvent les trois, même si l’utilisateur ne voit qu’un seul produit.
Si votre équipe déploie des applications Capacitor ou Electron, les bugs d'authentification restent rarement isolés. Ils apparaissent généralement sous la pression des releases, des besoins de rollback et des correctifs spécifiques à l'environnement. Capgo aide les équipes à déployer des mises à jour ciblées sur le code code et les assets de l’application sans attendre la revue des stores, ce qui facilite grandement la correction des flux de connexion, du traitement des callbacks et des problèmes d’authentification côté client lorsqu’ils se glissent en production.
