Probabilmente sei qui perché l'integrazione di Google Sign-In doveva essere veloce, e invece ti ritrovi davanti a una schermata di credenziali chiedendoti perché un tipo di app ti fornisca un client secret e un altro no. È un dubbio comune, specialmente se sviluppi con Capacitor, Ionic, Electron o uno stack ibrido web e native.
La parte che la maggior parte delle guide ignora è proprio quella che rompe le implementazioni reali: I Google Client ID sono specifici per piattaforma, e i tipi di app non-web spesso non ricevono un client secret per design. Se crei la credenziale sbagliata solo per forzare un secret nel flusso, finirai con un setup OAuth rotto e molto più difficile da debuggare del dovuto.
Indice dei contenuti
- Connettere la tua app all'ecosistema Google
- Cos'è un Google Client ID
- Come creare e visualizzare il tuo Client ID
- Configurazioni del Client ID per piattaforma
- Come proteggere le tue credenziali Google API
- Risolvere i comuni errori del Client ID
Connettere la tua app all'ecosistema Google
Molti team si scontrano con questo problema. Devono Accedi con Google, o vogliono l'accesso approvato dagli utenti a Drive o Calendar, e una chiave API smette improvvisamente di bastare.
Questo accade perché il login e l'accesso delegato passano tramite OAuth. Google ha bisogno di identificare la tua app, non solo la API che viene chiamata. La credenziale che lo fa è il ID Client Google.
Se lavori su un codebase cross-platform, la confusione peggiora in fretta. Potresti avere un frontend web, una shell Android, un'app iOS e magari una build Electron per desktop. Possono condividere il branding e la logica backend, ma non dovrebbero condividere un'unica identità OAuth.
Un setup OAuth pratico di solito si riduce a poche domande di implementazione:
- Quale tipo di applicazione creare
- Se ti serve un client secret
- Quali redirect URI o origin devono corrispondere esattamente
- Come collegare i flow mobile e web senza mischiare le credenziali
- Perché un flow che funziona nel browser fallisce dentro un wrapper nativo
Regola pratica: Se la tua app richiede permessi o l'accesso dell'utente, parti analizzando i tipi di client OAuth, non le chiavi API.
Questa distinzione fa risparmiare tempo fin da subito. Evita anche l'errore comune di costruire un flow di login mobile su una credenziale web solo perché la console mostrava più campi. Se stai implementando tutto questo in un'app Capacitor, questa guida su OAuth2 nelle app Capacitor è un ottimo supporto per il flusso lato app.
Cos'è un Google Client ID
Un Il client ID di Google OAuth 2.0 è l'identificativo pubblico della tua applicazione nel sistema di autenticazione di Google. Google lo descrive come lo username univoco di un'app quando richiede access token dagli endpoint di autenticazione, specificando che è diverso dalle chiavi API poiché viene usato nei flussi OAuth per verificare l'identità dell'app durante lo scambio di token, come spiegato nella documentazione OAuth client di Google Cloud.
Il modello mentale semplice
Think of the client ID di Google come all'identificativo della tua app username pubblico.
Comunica a Google che "questa richiesta proviene da questa applicazione registrata". È fondamentale durante il sign-in, il consenso, lo scambio di token e qualsiasi flusso in cui la tua app agisce per conto di un utente. Il client ID deve essere referenziato sia dalla tua app che dai server auth di Google.
L'errore comune è che questa credenziale viene spesso confusa con altri due concetti che non sono intercambiabili.
Client ID identifica l'app in OAuth.
chiave API identifica un progetto per determinate chiamate API che non richiedono l'autorizzazione delegata dell'utente.
Client secret è la controparte riservata, usata solo in flussi e tipi di app in grado di gestire segreti in sicurezza.
Molte integrazioni si rompono quando si trattano questi elementi come varianti della stessa cosa. Non lo sono.
L'uso pratico del client ID Google
Se hai bisogno Accedi con Google o One Tap, il client ID è il valore che il tuo frontend usa per avviare l'handshake di autenticazione. La documentazione di Google specifica inoltre che l'app deve essere registrata in un progetto dedicato su Cloud Console prima di generare le credenziali, e che le web app richiedono l'impostazione di JavaScript origins autorizzati o redirect URI con schema e hostname completi.
Ecco perché la configurazione sembra più rigida rispetto alla generazione di una semplice chiave. Google non sta solo abilitando l'accesso, sta vincolando la richiesta di auth a un'identità app nota.
Per i team che sviluppano app ibride, il modello mentale più sicuro è questo:
- Usa il client ID per identificare l'app
- Usa la schermata di consenso per presentare l'app all'utente
- Usa il tipo di app corretto per decidere se un secret debba far parte del flusso
Se desideri una panoramica più ampia su come l'identità dell'app e l'accesso delegato si integrano, questa guida sull'autorizzazione delle app è un ottimo ripasso.
Come creare e visualizzare il tuo Client ID
Il percorso nella console è cambiato così tanto che spesso gli sviluppatori pensano di essersi sbagliati. Di solito non è così. Google offre attualmente due percorsi di navigazione per queste credenziali: il più recente Piattaforma Google Auth > Clienti e il più vecchio API e servizi > Credenziali come descritto nella documentazione di configurazione di Google.
Inizia dall'area corretta della console
Apri la Google Cloud Console e seleziona o crea il progetto che gestirà la configurazione auth. Non disperdere l'auth su progetti casuali: rende l'auditing e il supporto molto difficili in seguito.
Da lì, vai in uno di questi due posti:
- Piattaforma Google Auth > Clienti
- API & Servizi > Credenziali
Se il tuo team visualizza etichette di navigazione diverse, è normale. Google sta separando la configurazione dell'identità dal resto della superficie delle credenziali API.
Crea le credenziali senza limitarti in futuro
Quando crei un nuovo client OAuth, la decisione più importante è il tipo di applicazione. Google ti chiede di scegliere un tipo specifico come Web, Android, iOS, o Desktop. Quella scelta non è estetica. Definisce come l'app viene identificata e quale configurazione di supporto è necessaria.
Per un'app web, dovrai inserire:
- Origini JavaScript autorizzate
- URI di reindirizzamento autorizzati
Questi valori devono essere esatti. Per le credenziali web, Google richiede lo schema e l'hostname completi, come https://www.example.com, invece di un generico dominio.
Per le piattaforme mobile, la struttura è diversa. La registrazione su Android richiede l'identità a livello di package e la verifica della proprietà, mentre iOS usa i propri identificatori di piattaforma. Se combini l'auth di Google con un altro layer di autenticazione, questa configurazione di Capacitor social login con Supabase è un ottimo esempio di come questi componenti si integrino. Per Neon Auth, la configurazione del plugin Neon spiega il concetto di fiducia https redirectTo regole di fiducia per OAuth, ma dovrai comunque registrare l'URI di reindirizzamento nella console di Google.
Questa guida può servirti come riferimento visivo per confrontare l'interfaccia mentre procedi con i clic:
Dove trovarlo in seguito
Dopo la creazione, il client ID apparirà nell'elenco delle credenziali del progetto. In quello stesso spazio è possibile abilitare le API e vedere come l'identità OAuth si collega alla schermata di consenso. Il nome dell'applicazione registrata è ciò che gli utenti vedono durante il prompt dei permessi, motivo per cui è fondamentale dare un nome accurato all'app.
Google mantiene queste credenziali gestibili nel tempo. Puoi tornare alla dashboard per copiare il client ID, rivedere le impostazioni e, dove applicabile, gestire il client secret associato a quella credenziale.
La schermata di consenso non è solo estetica. Fa parte del perimetro di fiducia. Gli utenti vedranno il nome della tua applicazione, non il nickname interno del tuo progetto.
Configurazioni del Client ID per piattaforma
Il modo più veloce per rompere il setup del login Google è pensare che un singolo client ID possa coprire ogni piattaforma. Non è così. Per le app multi-piattaforma, ogni piattaforma deve registrare il proprio client ID OAuth 2.0 distinto; la configurazione Android richiede specificamente lo SHA1 fingerprint per verificare la proprietà, come indicato in questo riferimento alla configurazione della piattaforma.
Perché un'app necessita di più client ID
Il tuo prodotto può essere un'unica app per l'utente, ma per Google è composta da molteplici client OAuth.
Un web app, un La build Android, un la build iOS, e un' app desktop non presentano le stesse proprietà di sicurezza. Non provano l'identità allo stesso modo e non memorizzano le credenziali in un ambiente affidabile. Google risolve il problema assegnando a ogni piattaforma il proprio modello di registrazione dell'app.
Questa separazione è una buona pratica di sicurezza. Se la configurazione delle credenziali di una piattaforma viene compromessa o configurata male, le altre non vengono esposte automaticamente.
Ecco la suddivisione pratica da seguire:
- Web utilizza un client ID web con corrispondenza rigorosa di origin e redirect URI.
- Android utilizza un client ID Android legato all'identità del package e al fingerprint SHA1.
- iOS utilizza un client ID iOS collegato al bundle ID dell'app.
- Desktop o Electron spesso usa un pattern OAuth desktop o installato invece di un flusso browser con secret.
Confronto tipi di Google Client ID
| Tipo di applicazione | Identificatore primario | Fornisce Client Secret? | Caso d'uso principale |
|---|---|---|---|
| Web | Origini JavaScript autorizzate e redirect URI | Solitamente sì | App browser e web OAuth con backend |
| Android | Package identity e fingerprint SHA1 | Spesso no | Sign-in nativo Android |
| iOS | Identità dell'app bundle | Spesso no | Sign-in nativo iPhone e iPad |
| Desktop | Identity dell'app installata | Spesso no | App desktop, inclusi i flussi nativi stile Electron |
Il paradosso del client secret per mobile e desktop
È qui che molti tutorial sbagliano.
Gli sviluppatori mobile e desktop spesso si aspettano che ogni client OAuth abbia sia un ID client che un client secret. Poi creano una credenziale Applicazione Web perché è l'unico modo per vedere un secret nella console. Il flusso sembra più completo, quindi procedono. In seguito, l'autenticazione si rompe in modi inspiegabili.
According to questa spiegazione del mismatch delle credenziali mobile, i tipi di applicazione non-web come Android, iOS e le app installate ricevono spesso un client ID ma non un client secret intenzionalmente, poiché Google non vuole un segreto riservato incorporato in software client-side dove gli utenti potrebbero estrarlo.
Questa scelta progettuale è corretta. Un'app mobile o un bundle Electron non sono repository sicuri per i segreti.
Cosa funziona: Flussi OAuth nativi o client-side progettati per client pubblici.
Cosa non funziona: Creare una credenziale web per un'app mobile solo per forzare l'inserimento di un secret nell'implementazione.
Per i team Capacitor, questo si manifesta solitamente in uno di questi due pattern errati:
- L'app avvia un flusso basato su browser usando un client web e poi cerca di comportarsi come un server riservato.
- L'app invia un client secret dal bundle code, annullando di fatto l'utilità di un segreto.
L'approccio migliore consiste nel trattare le app mobile e desktop come client pubblici. Nell'OAuth moderno, in genere significa usare un flow che non si basa su un secret nascosto dentro il client. Se è coinvolto il tuo backend, mantieni le operazioni confidenziali sul backend e limita l'app nativa a ciò che dovrebbe fare un client pubblico.
Un altro dettaglio sottile riguarda il sign-in su Android con Firebase. In questa configurazione, il client ID di tipo web application viene usato come OAuth client ID del server backend, mentre l'app Android mantiene la propria identità specifica per la piattaforma. Questa separazione confonde i team, perché vedono sia una credenziale web sia una mobile nello stesso progetto e pensano che una sostituisca l'altra. Non è così. Hanno ruoli diversi.
Se dovessi ricordare una sola regola, usa questa: scegli il tipo di client che corrisponde a dove gira code, non la forma della credenziale che vorresti avere.
Come proteggere le tue credenziali Google API
La maggior parte degli incidenti OAuth non è causata da attacchi complessi. I team fanno trapelare credenziali, allargano troppo le impostazioni di redirect o mettono secret in posti dove non sono mai stati al sicuro.
La guida OAuth di Google sottolinea che client ID e secret devono essere trattati come dati privati e, per le web app, il client ID viene verificato rispetto ai redirect URI pre-registrati. Se il redirect URI non corrisponde esattamente, Google rifiuta la richiesta. Questo binding dell'origin fa parte della protezione contro l'intercettazione dei token, come descritto nella guida alla registrazione dei client di OAuth.com.
Cosa mettere in sicurezza immediatamente
Se riesci a fare bene solo poche cose, fai queste:
- Non pubblicare mai un client secret nell'app code. I web bundle, i binari mobile e i pacchetti Electron sono ispezionabili dagli utenti.
- Registra gli URI di redirect esatti. Quasi giusto non basta. Google verifica corrispondenze esatte per i flussi web.
- Mantieni gli origin ristretti. Non autorizzare domini ampi solo per superare gli attriti della configurazione.
- Separa le credenziali per piattaforma. Non lasciare che la comodità spinga Android, iOS e web verso un'unica credenziale.
C'è un dettaglio operativo facile da sfuggire. Google permette di generare nuovi secret per un client ID esistente e disabilitare i vecchi. Conta quando un secret viene esposto o quando stai mettendo a punto il processo di deployment.
Cosa fanno davvero i team sicuri
I team che non corrono rischi trattano le credenziali OAuth come qualsiasi altro segreto di produzione.
Mantengono i client secret web sul backend, li iniettano tramite la gestione delle variabili d'ambiente e monitorano chi ha accesso alla console. Se stai ottimizzando la tua release pipeline, questa guida su gestire i segreti nelle pipeline CI/CD merita di essere applicata anche al tuo setup di auth.
Analizzano anche i metadati, non solo le chiavi. La schermata di consenso OAuth è legata all'identità del client che gli utenti vedono. Se il nome dell'app è vago o fuorviante, gli utenti saranno più propensi a diffidare del prompt o ad approvare l'app sbagliata.
La sicurezza non consiste solo nel nascondere un segreto. Significa anche assicurarsi che l'identità dell'app, i redirect target e la schermata di approvazione siano sempre coerenti.
Risoluzione dei comuni errori del Client ID
La maggior parte dei fallimenti di Google OAuth deriva da un piccolo set di errori di configurazione. Il messaggio di errore non è sempre chiaro, ma il problema alla base è solitamente semplice una volta capito dove guardare.
Le soluzioni per la maggior parte dei problemi
redirect_uri_mismatch
La tua app sta inviando un redirect URI che non corrisponde esattamente a quello registrato per quel web client. Controlla lo scheme, l'host, il path e ogni minima differenza finale. Per l'OAuth web, il matching esatto è parte integrante del modello di sicurezza.
invalid_client
Solitamente significa che l'app sta inviando il client ID errato, il secret sbagliato per quel client, o sta mescolando le credenziali tra diverse piattaforme. Un esempio comune è un flusso Android o iOS che usa accidentalmente le credenziali web nel posto sbagliato.
invalid_request
Questo errore è generico, ma nelle app cross-platform spesso indica parametri di autenticazione malformati o un flusso non adatto al tipo di client. Controlla se l'app sta cercando di includere un secret dove non dovrebbe, o se il flusso OAuth selezionato richiede un tipo di client differente.
Google Sign-In funziona sul web ma fallisce su mobile
La prima cosa da controllare è il tipo di client. L'errore più comune per gli sviluppatori mobile è creare un client ID di tipo web solo per ottenere un client secret, quando invece dovrebbero usare i tipi Android o iOS che spesso omettono intenzionalmente il secret, come spiegato in questa analisi del mismatch del client secret. Se la tua implementazione include la gestione del ciclo di vita dei token dopo il sign-in, è utile anche quella guida sulla revoca.
Il login su Android fallisce dopo la creazione delle credenziali
Verifica il fingerprint SHA1 associato al client Android. Se l'identità di firma non corrisponde a quanto previsto da Google, l'app non riuscirà a dimostrare correttamente la proprietà.
La schermata di consenso appare errata
Verifica il nome dell'applicazione e il branding associati alla configurazione OAuth nella console. Gli utenti autorizzano ciò che vedono, quindi metadati errati creano sia problemi di fiducia che un aumento delle richieste di supporto.
L'ordine pratico per il debugging è semplice: controlla prima il tipo di client, poi reindirizza le impostazioni, poi gli identificativi della piattaforma e infine se un segreto debba far parte del flusso.
Se il tuo team rilascia app Capacitor o Electron, i bug di autenticazione raramente restano isolati. Di solito emergono insieme alla pressione dei rilasci, alla necessità di rollback e ai fix specifici per l'ambiente. Capgo aiuta i team a rilasciare aggiornamenti mirati per l'app code e gli asset senza attendere la revisione degli store, rendendo molto più semplice correggere i flussi di login, la gestione dei callback e i problemi di auth lato client quando arrivano in produzione.
