Vous êtes probablement ici parce que Google Sign-In aurait dû être une intégration rapide, mais vous vous retrouvez face à un écran d'identifiants en vous demandant 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.
Ce que la plupart des guides oublient est précisément ce qui casse les implémentations réelles : Les client IDs Google sont spécifiques à chaque plateforme, et les types d'applications non-web ne reçoivent souvent pas de client secret par conception. Si vous créez les mauvais identifiants juste pour forcer un secret dans le flux, vous finirez généralement avec une configuration OAuth défaillante, bien plus difficile à déboguer qu'elle ne devrait l'être.
Table of Contents
- Connecter votre application à l'écosystème Google
- Qu'est-ce qu'un client ID Google ?
- Comment créer et consulter votre client ID
- Configurations du client ID selon la plateforme
- Sécuriser vos identifiants Google API
- Dépanner les erreurs courantes de Client ID
Connecter votre application à l'écosystème Google
De nombreuses équipes rencontrent ce problème au même moment. Elles ont besoin de Se connecter avec Google, ou elles veulent un accès approuvé par l'utilisateur à des services comme Drive ou Calendar, et une clé API ne suffit soudainement plus.
C'est parce que la connexion utilisateur et l'accès délégué passent par OAuth. Google a besoin d'un moyen d'identifier your app, et pas seulement l’API appelé. L'identifiant qui effectue cela est le Client ID Google.
Si vous travaillez sur une base de code cross-platform, la confusion s'accentue rapidement. Vous pouvez avoir un frontend web, une coquille Android, une app iOS et peut-être un build Electron pour le desktop. Ils peuvent partager le branding et la logique backend, mais ils ne doivent pas tous partager la même identité OAuth.
Une configuration OAuth pratique se résume généralement à quelques questions d'implémentation :
- Quel type d'application vous devez créer
- Si vous avez besoin d'un client secret
- Quelles URI de redirection ou origines doivent correspondre exactement
- Comment lier les flux mobile et web sans mélanger les identifiants
- Pourquoi un flux qui fonctionne dans le navigateur échoue dans un wrapper natif
Règle pratique : Si votre app demande une permission utilisateur ou une connexion, commencez par réfléchir en types de clients OAuth, et non en clés API.
Cette distinction fait gagner du temps dès le départ. Elle évite aussi l'erreur classique de construire un flux de connexion mobile autour d'un identifiant web simplement parce que la console affichait plus de champs. Si vous implémentez cela dans une app Capacitor, ce guide sur OAuth2 dans les apps Capacitor est un compagnon utile pour le flux côté application.
Qu'est-ce qu'un client ID Google
R Le client ID 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 client OAuth de Google Cloud.
Le modèle mental simple
Considérez le ID client Google problèmes comme étant l' nom d'utilisateur public.
Cela indique à Google : « cette requête provient de cette application enregistrée ». C'est crucial lors de la connexion, du consentement, de l'échange de token et de tout flux où votre application agit au nom d'un utilisateur. Le client ID est destiné à être référencé à la fois par votre application et par les serveurs d'auth de Google.
Ce qui perd les développeurs, c'est que cet identifiant côtoie 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 ne nécessitent pas d'autorisation utilisateur déléguée.
Secret client est le contrepartie confidentielle utilisée uniquement dans les flux et les types d'app qui peuvent conserver des secrets en toute sécurité.
De nombreuses intégrations défectueuses surviennent lorsque l'on traite ces éléments comme des variantes d'une même chose. Ce n'est pas le cas.
L'usage concret du client ID Google
If you need Se connecter avec Google ou One Tap, le client ID est la valeur que votre frontend utilise pour initier le handshake d'authentification. La documentation de Google précise également que l'application doit être enregistrée dans un projet Cloud Console dédié avant de pouvoir générer l'identifiant, et que les applications web nécessitent la configuration d'origines JavaScript autorisées ou d'URI de redirection incluant le schéma et l'hôte complets.
C'est pourquoi la configuration semble plus stricte que la génération d'une simple clé. Google ne se contente pas d'autoriser l'accès : il lie la requête d'authentification à une identité d'application connue.
Pour les équipes qui développent des applications hybrides, voici le modèle mental le plus sûr :
- Utilisez le client ID pour identifier l'application
- Utilisez l'écran de consentement pour représenter l'application à l'utilisateur
- Utilisez le type d'application correct pour déterminer si un secret doit être inclus dans le flux
Si vous souhaitez un guide plus large sur la relation entre l'identité de l'application et l'accès délégué, ce guide sur l'autorisation d'application est un bon rappel.
Comment créer et consulter votre client ID
Le chemin dans la console a tellement changé que les développeurs pensent souvent s'être trompés d'endroit. En général, ce n'est pas le cas. Google propose actuellement deux routes de navigation pour ces identifiants : la plus récente, Google Auth Platform > Clients et l'ancienne, APIs & Services > Identifiants comme décrit dans la documentation de configuration de Google.
Commencez dans la bonne zone de la console
Ouvrez la console Google Cloud et sélectionnez ou créez le projet qui possédera la configuration d'auth. Ne dispersez pas l'auth sur des projets aléatoires. Cela rend l'audit et le support pénibles par la suite.
De là, rendez-vous dans l'un de ces deux endroits :
- Google Auth Platform > Clients
- API et services > Identifiants
Si votre équipe voit des libellés de navigation différents, c'est normal. Google a séparé la configuration de l'identité du reste de la surface d'identification API.
Créez l'identifiant sans vous enfermer
Lorsque vous créez un nouveau client OAuth, la décision la plus importante est le type d'application. Google vous demande de choisir un type précis tel que Web, Android, iOS, ou Desktop. Ce choix n'est pas cosmétique. Il définit comment l'app est identifiée et quelle configuration associée est nécessaire.
Pour une application web, vous devrez saisir :
- Origines JavaScript autorisées
- URI de redirection autorisées
Ces valeurs doivent être exactes. Pour un identifiant web, Google attend le schéma et l'hôte complets, comme https://www.example.com, plutôt qu'un simple nom de domaine.
Pour les plateformes mobiles, la structure est différente. L'enregistrement Android nécessite une identité au niveau du package et une vérification de propriété, tandis qu'iOS utilise ses propres identifiants de plateforme. Si vous combinez l'auth Google avec une autre couche d'authentification, cette configuration de Capacitor social login avec Supabase est un bon exemple de la manière dont ces éléments s'articulent.
Ce guide constitue une bonne référence visuelle si vous souhaitez comparer l'interface utilisateur tout en suivant les étapes :
Où le retrouver plus tard
Une fois créé, le client ID apparaît dans la liste des identifiants du projet. C'est aussi dans cet espace projet que les équipes activent les API et voient comment l'identité OAuth se connecte à l'écran de consentement. Le nom de l'application enregistrée est ce que les utilisateurs voient lors du prompt de permission, d'où l'importance de nommer l'app correctement.
Google permet de gérer ces identifiants facilement dans le temps. Vous pouvez retourner sur le dashboard pour copier le client ID, réviser les paramètres et, le cas échéant, gérer le client secret associé à cet identifiant.
L'écran de consentement n'est pas une simple décoration. Il fait partie du périmètre de confiance. Les utilisateurs y voient le nom de votre application, pas le surnom de votre projet interne.
Configurations des client ID par plateforme
La façon la plus rapide de casser une configuration de connexion Google est de supposer qu'un seul client ID peut couvrir toutes les plateformes. Ce n'est pas le cas. Pour les applications multiplateformes, chaque plateforme doit enregistrer son propre client ID OAuth 2.0 distinct, et la configuration Android nécessite spécifiquement l'empreinte SHA1 pour vérifier la propriété, comme indiqué dans cette référence de configuration par plateforme.
Pourquoi une application nécessite plusieurs client IDs
Votre produit peut n'être qu'une seule application pour l'utilisateur, mais pour Google, ce sont plusieurs clients OAuth.
R web app, un build Android, un build iOS, et une application desktop ne présentent pas les mêmes propriétés de sécurité. Ils ne prouvent pas l'identité de la même manière et ne stockent pas tous les identifiants dans un environnement de confiance. Google gère cela en attribuant à chaque plateforme son propre modèle d'enregistrement d'application.
Cette séparation est une bonne pratique de sécurité. Si la configuration des identifiants d'une plateforme est compromise ou mal configurée, les autres ne sont pas automatiquement exposées.
Voici la répartition pratique à suivre :
- 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 client ID iOS lié à l'identité du bundle de l'application.
- Desktop ou Electron utilise souvent un modèl’OAuth installé ou de type desktop plutôt qu'un flux navigateur basé sur un secret.
Comparaison des types de Client ID Google
| Type d'application | Identifiant principal | Fournit un Client Secret ? | Cas d'usage clé |
|---|---|---|---|
| Web | Origines JavaScript autorisées et URIs de redirection | Généralement oui | Apps navigateur et OAuth web assisté par un backend |
| Android | Identité du package plus empreinte SHA1 | Souvent non | Connexion Android native |
| iOS | Identité du bundle de l'app | Souvent non | Connexion iPhone et iPad native |
| Desktop | Identité de l'app installée | Souvent non | Apps desktop, incluant les flux natifs de type Electron |
Le paradoxe du client secret pour le mobile et le desktop
C'est l'étape que beaucoup de tutoriels ratent.
Les développeurs mobile et desktop s'attendent souvent à ce que chaque client OAuth soit fourni avec un ID client et un secret client. Ils créent alors un Application web credential car c'est la seule façon de voir un secret dans la console. Le flux semble plus complet, alors ils continuent. Plus tard, l'authentification échoue de manière confuse.
According to cette explication sur l'incohérence des credentials mobiles, les types d'applications non-web comme Android, iOS et les apps installées ne reçoivent souvent qu'un client ID sans client secret, et ce intentionnellement, car Google ne veut pas qu'un secret confidentiel soit intégré dans un logiciel côté client où les utilisateurs peuvent l'extraire.
Ce choix de conception est le bon. Une application mobile ou un bundle Electron n'est pas un lieu sûr pour stocker des secrets.
Ce qui fonctionne : Flux OAuth natifs ou côté client conçus pour les clients publics.
Ce qui ne convient pas : Créer un identifiant web pour une application mobile juste pour forcer l'usage d'un secret dans l'implémentation.
Pour les équipes Capacitor, cela se manifeste généralement par l'un de ces deux mauvais patterns :
- L'application lance un flux via un navigateur en utilisant un client web puis tente de se comporter comme un serveur confidentiel.
- L'application envoie un secret client depuis le bundle code, ce qui annule tout l'intérêt d'avoir un secret.
La meilleure approche consiste à traiter les applications mobiles et desktop comme des clients publics. Dans l'OAuth moderne, cela signifie généralement utiliser un flux qui ne repose pas sur un secret caché à l'intérieur du client. Si votre backend est impliqué, gardez les opérations confidentielles sur le backend et limitez l'application native à ce qu'un client public doit faire.
Un autre point subtil est important pour la connexion Android via 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 sa propre identité spécifique à la plateforme. Cette séparation déroute les équipes car elles voient à la fois un identifiant web et un identifiant mobile dans le même projet et supposent que l'un remplace l'autre. Ce n'est pas le cas. Ils remplissent des rôles différents.
Si vous ne devez retenir qu'une règle, c'est celle-ci : choisissez le type de client correspondant à l'endroit où s'exécute code, et non le format d'identifiant que vous souhaiteriez avoir.
Sécuriser vos identifiants Google API
La plupart des incidents OAuth ne sont pas causés par des attaques complexes. Les équipes laissent fuiter des identifiants, élargissent trop les paramètres de redirection ou placent des secrets dans des endroits qui n'ont jamais été sûrs dès le départ.
Les directives OAuth de Google soulignent que les client IDs et les secrets doivent être traités comme des données privées. Pour les applications web, le client ID est vérifié par rapport aux URI de redirection pré-enregistrées. Si l'URI de redirection ne correspond pas strictement, Google rejette la requête. Cette liaison d'origine fait partie de la protection contre l'interception de token, comme décrit dans les directives d'enregistrement de client d'OAuth.com.
Ce qu'il faut sécuriser immédiatement
If you only do a few things right, do these:
- Never ship a client secret in app code. Les bundles web, les binaires mobiles et les packages Electron sont inspectables par les utilisateurs.
- Enregistrez des URI de redirection exactes. « Presque identique » ne suffit pas. Google exige une correspondance exacte pour les flux web.
- Limitez strictement les origines. N'autorisez pas de domaines trop larges simplement pour faciliter la configuration.
- Séparez les identifiants par plateforme. Ne laissez pas la facilité fusionner Android, iOS et le web sous un seul identifiant.
Un détail opérationnel est facile à oublier. Google permet aux équipes de générer de nouveaux secrets pour un client ID existant et de désactiver les anciens. C'est crucial lorsqu'un secret est exposé ou lorsque vous renforcez votre processus de déploiement.
Ce que font réellement les équipes sécurisées
Les équipes qui évitent les problèmes traitent les identifiants OAuth comme n'importe quel autre secret de production.
Elles conservent les secrets du client web sur le backend, les injectent via la gestion des environnements et auditent qui possède un accès à la console. Si vous nettoyez votre pipeline de release, ce guide sur la gestion des secrets dans les pipelines CI/CD is worth applying to your auth setup too.
Elles examinent aussi les métadonnées, pas seulement les clés. L'écran de consentement OAuth est lié à l'identité du client que voient les utilisateurs. Si le nom de l'application est vague ou trompeur, les utilisateurs seront plus enclins à se méfier du prompt ou à approuver la mauvaise application.
La sécurité ne consiste pas seulement à cacher un secret. Il s'agit aussi de s'assurer que l'identité de l'app, les cibles de redirection et l'écran d'approbation correspondent parfaitement à chaque fois.
Dépanner les erreurs courantes de Client ID
La plupart des échecs Google OAuth proviennent d'un petit nombre d'erreurs de configuration. Le message d'erreur n'est pas toujours explicite, mais le problème sous-jacent est généralement simple une fois que l'on sait où chercher.
Les correctifs qui résolvent la plupart des échecs
redirect_uri_mismatch
Votre app 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 de terminaison. Pour l'OAuth web, la correspondance exacte fait partie du modèle de sécurité.
invalid_client
Cela signifie généralement que l'app envoie le mauvais client ID, le mauvais secret pour ce client, ou mélange les identifiants entre les plateformes. Un exemple courant est un flux Android ou iOS utilisant accidentellement l'identifiant web au mauvais endroit.
invalid_request
C'est un message assez large, mais dans les apps cross-platform, il indique souvent des paramètres d'auth malformés ou un flux qui ne correspond pas au type de client. Vérifiez si l'app tente d'inclure un secret là où elle ne devrait pas, ou si le flux OAuth sélectionné attend un autre type de client.
Google Sign-In fonctionne sur le web mais échoue sur mobile
La première chose à inspecter est le type de client. L'erreur la plus courante pour les développeurs mobiles est de créer un client ID de type application web juste pour obtenir un client secret, alors qu'ils devraient utiliser des types Android ou iOS qui omettent souvent volontairement le secret, comme expliqué dans cette analyse de l'incohérence du client secret. Si votre implémentation inclut la gestion du cycle de vie des tokens après la connexion, ce guide de révocation sera également utile.
L'authentification Android échoue après la création des identifiants
Vérifiez l'empreinte SHA1 associée au client Android. Si l'identité de signature ne correspond pas à celle attendue par Google, l'application ne pourra pas prouver son identité correctement.
L'écran de consentement semble incorrect
Vérifiez le nom de l'application et le branding associés à la configuration OAuth dans la console. Les utilisateurs autorisent ce qu'ils voient, donc des métadonnées incorrectes créent des problèmes de confiance et du bruit pour le support.
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.
Si votre équipe déploie des apps Capacitor ou Electron, les bugs d'auth restent rarement isolés. Ils apparaissent souvent lors de la pression des releases, des besoins de rollback ou de correctifs spécifiques à un environnement. Capgo aide les équipes à déployer des mises à jour ciblées sur le code et les assets de l'app sans attendre la revue des stores, ce qui facilite grandement la correction des flux de login, de la gestion des callbacks et des problèmes d'auth côté client lorsqu'ils arrivent en production.
