Sembra che tu sia qui perché il Sign-In di Google dovrebbe essere stata un'integrazione rapida, e invece ti trovi di fronte a una schermata di credenziali che ti fa domande sul perché un tipo di app ti dà un segreto client e un'altra no. Quella confusione è normale, soprattutto se stai costruendo con Capacitor, Ionic, Electron o una pila mista web e nativa.
La parte che più guide trascurano è proprio quella che rompe le implementazioni reali: ID Clienti Google sono specifici della piattaforma, e i tipi di applicazione non web spesso non ricevono un segreto client per design. Se crei le credenziali sbagliate solo per forzare un segreto nel flusso, di solito finisci con un setup OAuth rotto che è più difficile da debuggare di quanto dovrebbe essere.
Elenco dei contenuti
- Collegare la tua app all'ecosistema Google
- Cosa è un ID Client Google
- Come creare e visualizzare il tuo ID Client
- Configurazioni di ID client specifiche per piattaforma
- La sicurezza dei tuoi credenziali Google API
- Risolvere gli errori comuni di ID client
Collega la tua app all'ecosistema Google
Molti team si trovano in questo problema nello stesso momento. Hanno bisogno Accedi con Googleo desiderano un accesso approvato da parte dell'utente a qualcosa come Drive o Calendario, e un API chiave improvvisamente non è più sufficiente.
Questo accade perché l'accesso all'utente e l'accesso delegato passano attraverso OAuth. Google ha bisogno di una via per identificare il tuo appe non solo il API in corso. Il credenziale che lo fa è il ID Client Google.
Se stai lavorando in un codice cross-platform, la confusione peggiora rapidamente. Potresti avere un frontend web, un shell Android, un'app iOS e forse un build Electron per desktop. Possono condividere la branding del prodotto e la logica del backend, ma non dovrebbero condividere un'identità OAuth.
Un setup OAuth pratico si riduce a poche domande di implementazione:
- Qual tipo di applicazione dovresti creare
- Se hai bisogno di un segreto client
- Quali URI di reindirizzamento o origini devono corrispondere esattamente
- Come collegare i flussi mobili e web senza mescolare le credenziali
- Why a flow that works in the browser fails inside a wrapper nativo
Regola pratica: Se il tuo app richiede il permesso dell'utente o l'accesso, inizia a pensare ai tipi di client OAuth, non ai API chiavi.
Questa distinzione salva tempo inizialmente. Inoltre, evita l'errore comune di creare un flusso di accesso mobile basato su un credenziale web solo perché il console mostrava più campi. Se stai implementando questo in un'app Capacitor, questo guida su OAuth2 negli app Capacitor è un utile compagno per il flusso dell'app.
Cosa è un ID Client Google
A ID Client OAuth 2.0 di Google è l'identificatore pubblico per la tua applicazione nel sistema di autenticazione di Google. Google lo descrive come l'username unico per un'applicazione quando richiede token di accesso da endpoint di autenticazione di Google, e nota che è distinto dalle API chiavi perché viene utilizzato nei flussi OAuth per verificare l'identità dell'app durante l'interscambio di token, come spiegato in la documentazione dei client OAuth di Google Cloud.
Modello mentale semplice
Pensa al ID client Google i problemi come il tuo username pubblico Lo comunica a Google, 'questa richiesta proviene da questa applicazione registrata.' Ciò è importante durante l'accesso, il consenso, l'interscambio di token e in ogni flusso in cui il tuo app chiede di agire in nome di un utente. L'ID client è destinato a essere riferito sia dalla tua app che dai server di autenticazione di Google..
Ciò che confonde le persone è che questo credenziale si trova accanto a due altri concetti che non sono intercambiabili.
ID client
identifica l'app in OAuth. chiave __CAPGO_KEEP_0__
identifica un progetto per certe chiamate API che non coinvolgono l'autorizzazione dell'utente delegata. identifies a project for certain API calls that don’t involve delegated user authorization.
segreto client è il controparte riservata utilizzato solo in flussi e tipi di app che possono sicuramente mantenere segreti.
Un sacco di integrazioni rotte iniziano quando qualcuno tratta questi come variazioni della stessa cosa. Non lo sono.
Dove il client ID Google si inserisce nella pratica
Se hai bisogno Accedi con Google o Perché le integrazioni con Google sono così complesse?Un solo tocco
, il client ID è il valore che il tuo frontend utilizza per iniziare il negoziato di autenticazione. La documentazione di Google nota anche che l'app deve essere registrata in un progetto Cloud Console dedicato prima che il credenziale possa essere generato, e che le app web richiedono origine JavaScript autorizzata configurata o URIs di reindirizzamento con schema e hostname completi.
È per questo che la configurazione sembra più rigorosa di quanto generare una semplice chiave. Google non sta solo abilitando l'accesso. Sta legando la richiesta di autenticazione a un'identità di app nota.
- Per le squadre che stanno costruendo app ibride, il modello mentale più sicuro è questo:
- Utilizza il client ID per identificare l'applicazione
- Usa il tipo di app corretto per determinare se un segreto appartiene al flusso
Se desideri una panoramica più ampia su come l'identità dell'app e l'accesso delegato si integrano a vicenda questa guida all'autorizzazione dell'app è un buon rinfrescamento.
Crea e visualizza il tuo ID del client
La cartella del console è cambiata abbastanza da far pensare ai developer che si trovino nel posto sbagliato. Di solito non è così. Google esporre attualmente due percorsi di navigazione per questi credenziali: il nuovo Google Auth Platform > Clienti e il più vecchio APIs & Services > Credenziali come descritto in la documentazione di configurazione di Google.
Avvia nell'area del console giusta
Apre il Cloud Console di Google e seleziona o crea il progetto che possiederà la configurazione di autenticazione. Non disperdere l'autenticazione in progetti random. Ciò rende l'audit e il supporto dolorosi in seguito.
Dal lì, vai in uno di questi luoghi:
- Piattaforma di autenticazione di Google > Clienti
- Credenziali > Servizi e API
If your team sees different navigation labels, that’s expected. Google has been separating identity setup from the rest of the API credential surface.
Crea la credenziale senza rinchiuderti
Quando si crea un nuovo client OAuth, la decisione più grande è il tipo di applicazione. Google ti chiede di scegliere un tipo specifico come Web, Android, iOS, o Desktop. Questa scelta non è estetica. Definisce come l'app viene identificata e quali configurazioni di supporto sono richieste.
For a web app, attenditi:
- Origini JavaScript autorizzate
- URI di reindirizzamento autorizzati
Quei valori devono essere esatti. Per un credenziale web, Google aspetta il pieno schema e il nome host, come https://www.example.com, anziché un concetto di dominio rilassato.
For mobile platforms, la forma è diversa. La registrazione Android richiede identità e verifica di proprietà a livello di pacchetto, mentre iOS utilizza i suoi propri identificatori di piattaforma. Se stai combinando l'autenticazione Google con un'altra layer di autenticazione, questo Capacitor setup di accesso sociale con Supabase è un esempio utile di come questi pezzi si adattano spesso l'uno all'altro.
Questa guida passo passo è una buona riferimento visivo se desiderate confrontare l'interfaccia utente mentre cliccate attraverso:
Dove trovarlo in seguito
Dopo la creazione, l'ID del client compare nella lista delle credenziali del progetto. Lo stesso spazio del progetto è anche dove le squadre abilitano le API e visualizzano come l'identità OAuth si connette alla schermata di consenso. Il nome dell'applicazione registrata è ciò che gli utenti vedono durante la richiesta di autorizzazione, il che è una delle ragioni per cui nominare l'app con precisione è importante.
Google mantiene queste credenziali gestibili nel tempo. Potete tornare alla dashboard per copiare l'ID del client, esaminare le impostazioni e, ove applicabile, gestire il segreto del client associato a quella credenziale.
La schermata di consenso non è solo decorativa. È parte del confine di fiducia. Gli utenti vedono il nome dell'applicazione lì, non il nickname del progetto interno.
Configurazioni dell'ID del client specifiche della piattaforma
Il modo più veloce per rompere una configurazione di accesso Google è assumere che un ID del client possa coprire ogni piattaforma. Non può. Per le app multi-piattaforma, ogni piattaforma deve registrare il proprio ID del client OAuth 2.0 distinto e, in particolare, la configurazione di Android richiede il fingerprint SHA1 per verificare la proprietà, come riportato in.
Questa guida di riferimento per la configurazione della piattaforma
Perché un'app necessiti di più ID del client
Il tuo prodotto può essere un'app unica per l'utente, ma è più di un client OAuth per Google. A. App webe an costruzione di un'app Androide an costruzione di un'app iOSe una app desktop non presentano le stesse proprietà di sicurezza. Non dimostrano l'identità nello stesso modo e non archiviano tutti i credenziali in un ambiente affidabile. Google gestisce questo aspetto fornendo a ogni piattaforma il proprio modello di registrazione dell'app.
Questa separazione è un buon igiene della sicurezza. Se la configurazione dei credenziali di una piattaforma è compromessa o configurata in modo errato, le altre non sono automaticamente esposte.
Ecco lo split pratico da seguire:
- Web utilizza un ID del client web e un matching di origine e URI di reindirizzamento rigoroso.
- Android utilizza un ID del client Android legato all'identità del pacchetto e alla firma SHA1.
- iOS utilizza un ID del client iOS legato all'identità del bundle dell'applicazione.
- Desktop o Electron di solito utilizza un modello OAuth installato o a stile desktop al posto di un flusso del browser basato su una chiave segreta.
Tipi di ID del client Google confrontati
| Tipo di applicazione | Identificatore principale | Si fornisce una chiave segreta? | Utilizzo chiave |
|---|---|---|---|
| Web | Origini JavaScript autorizzate e URIs di reindirizzamento | Di solito sì | Applicazioni del browser e OAuth assistito da backend |
| Android | Identità del pacchetto più impronta SHA1 | Di solito no | Accesso all'app Android nativa |
| iOS | Identità del bundle dell'app | Di solito no | Accesso all'app iPhone e iPad nativo |
| Desktop | Identità dell'app installata | Spesso no | Applicazioni desktop, compresi flussi nativi di stile Electron |
Il paradosso del segreto del client per mobile e desktop
Questo è il punto in cui molti tutorial sbagliano.
Gli sviluppatori di mobile e desktop spesso aspettano che ogni client OAuth venga fornito con sia un ID del client che un segreto del client. Poi creano un credenziale di Applicazione Web perché è l'unico modo in cui possono vedere un segreto nella console. Il flusso sembra più completo, quindi continuano. In seguito, l'autenticazione si rompe in modi confusi.
Secondo Spiegazione dell'incongruenza dei credenziali mobili, non applicazioni web tipo come Android, iOS e applicazioni installate ricevono spesso un ID client ma nessun segreto client intenzionalmente, perché Google non vuole che un segreto confidenziale sia inserito nel software di client-side dove gli utenti possono estrarlo.
Quella scelta di design è corretta. Un'app mobile o un bundle di Electron non è un magazzino di segreti sicuro.
Cosa funziona: Flussi OAuth nativi o client-side progettati per client pubblici.
Cosa non funziona: Creare un credenziale web per un'app mobile solo per forzare un segreto nell'implementazione.
Per Capacitor team, questo si manifesta spesso in uno dei due cattivi pattern:
- L'app avvia un flusso basato su browser utilizzando un cliente web e poi cerca di comportarsi come un server confidenziale.
- L'app invia un segreto del client da code integrato, che sconfessa lo scopo di avere un segreto.
La migliore approccio è trattare le app mobili e desktop come client pubblici. In OAuth moderno, ciò significa generalmente utilizzare un flusso che non dipende da un segreto nascosto all'interno del client. Se il tuo backend è coinvolto, mantieni le operazioni riservate sul backend e limita l'app nativa a ciò che un client pubblico dovrebbe fare.
Un altro punto sottile è importante per l'accesso di Firebase all'Android. In tale configurazione, l'ID del client di tipo applicazione web è utilizzato come ID del client OAuth del server backend, mentre l'app Android mantiene la propria identità specifica per piattaforma. Tale divisione confonde le squadre perché vedono sia una credenziale web che una credenziale mobile nello stesso progetto e suppongono che una sostituisca l'altra. Non è così. Sono destinati a ruoli diversi. Se ricordi una regola, utilizza questa: Scegli il tipo di client che corrisponde a dove si esegue __CAPGO_KEEP_0__, non la forma della credenziale che desideri avere
La sicurezza dei tuoi __CAPGO_KEEP_0__ Google choose the client type that matches where the code runs, not the credential shape you wish you had.
Securing Your Google API Credentials
L'approccio migliore è trattare le app mobili e desktop come
La guida di autenticazione OAuth di Google sottolinea che gli ID client e i segreti devono essere trattati come dati privati, e per le app web l'ID client è impostato contro gli URI di reindirizzamento pre-registrati. Se l'URI di reindirizzamento non corrisponde esattamente, Google rifiuta la richiesta. Quella vincolazione di origine fa parte della protezione contro l'intercettazione di token, come descritto in La guida di registrazione degli ID client di OAuth.com.
Cosa bloccare immediatamente
Se fai solo poche cose al meglio, fai queste:
- Non spedire mai un segreto client all'interno dell'app code. I bundle web, i binari mobili e i pacchetti Electron sono ispezionabili dagli utenti.
- Registra URI di reindirizzamento esatti. Non basta essere vicini. Google valuta match esatti per flussi web.
- Tieni le origini strette. Non autorizzare domini ampi solo per superare la frizione di configurazione.
- Separare le credenziali delle piattaforme. Non lasciare che la comodità faccia scomparire Android, iOS e web in un unico credenziale.
Un dettaglio operativo è facile da trascurare. Google consente alle squadre di generare nuovi segreti per un ID client esistente e disabilitare quelli vecchi. Ciò conta quando un segreto è stato esposto o quando si sta stringendo il processo di distribuzione.
Cosa fanno le squadre sicure
Le squadre che evitano problemi trattano i credenziali OAuth come ogni altro segreto di produzione.
Conservano i segreti dei client web sul backend, li iniettano attraverso la gestione dell'ambiente e controllano chi ha accesso alla console. Se si sta pulendo il pipeline di rilascio, questa guida sul gestione dei segreti nei pipeline CI/CD è anche utile per la configurazione di autenticazione.
Rivisitano anche i metadati, non solo le chiavi. Lo schermo di consenso OAuth è legato all'identità del client che gli utenti vedono. Se il nome dell'applicazione è vago o ingannevole, gli utenti sono più propensi a non fidarsi della richiesta o a approvare l'applicazione sbagliata.
La sicurezza non è solo nascondere un segreto. È anche assicurarsi che l'identità dell'app corretta, i target di reindirizzamento e lo schermo di approvazione si allineino ogni volta.
Risolvere gli errori comuni dell'ID client
La maggior parte degli errori OAuth di Google deriva da un piccolo insieme di errori di configurazione. Il testo dell'errore non è sempre gentile, ma la causa sottostante è solitamente chiara una volta che si sa dove cercare.
Le soluzioni che risolvono la maggior parte degli errori
redirect_uri_mismatch
La tua app sta inviando un URI di reindirizzamento che non corrisponde esattamente a quanto registrato per quel client web. Controlla lo schema, l'host, la path e qualsiasi differenza finale. Per OAuth web, il matching esatto fa parte del modello di sicurezza.
invalid_client
Questo solitamente significa che l'app sta inviando il client ID sbagliato, il segreto sbagliato per quel client o sta mescolando le credenziali tra piattaforme. Un esempio comune è un flusso Android o iOS che accidentalmente utilizza le credenziali web nel posto sbagliato.
invalid_request
Questo è un problema ampio, ma nei casi di app cross-platform spesso indica parametri di autenticazione malformati o un flusso che non si adatta al tipo di client. Controlla se l'app sta cercando di includere un segreto dove non dovrebbe, o se il flusso OAuth selezionato aspetta un tipo di client diverso.
Google Sign-In funziona su web ma fallisce su mobile
La prima cosa da controllare è il tipo di client. La fonte più comune di errore per gli sviluppatori di mobile è la creazione di un client ID di applicazione web solo per ottenere un segreto del client, quando dovrebbero utilizzare tipi Android o iOS che spesso omettono il segreto intenzionalmente, come spiegato in questa spiegazione del mismatch del segreto del client. Se la tua implementazione include il lavoro sul ciclo di vita dei token dopo l'accesso, quella guida di revoca è utile anche.
L'accesso Android fallisce dopo la creazione delle credenziali
Duplica il controllo della firma SHA1 associata al client Android. Se l'identità di firma non corrisponde a quanto Google aspetta, l'app non dimostrerà la proprietà correttamente.
La schermata di consenso sembra sbagliata
Verifica il nome dell'applicazione e la marca associata alla configurazione OAuth nel console. Gli utenti autorizzano ciò che vedono lì, quindi i metadati errati creano sia problemi di fiducia che rumore di supporto.
Ordine di debug pratico è semplice: controlla il tipo di client prima, poi le impostazioni di reindirizzamento, poi gli identificatori di piattaforma, poi se un segreto appartiene al flusso in generale.
Se il tuo team invia Capacitor o app Electron, i bug di autenticazione sono raramente isolati. Di solito emergono insieme alla pressione di rilascio, alle esigenze di rollback e alle correzioni specifiche dell'ambiente. Capgo aiuta i team a inviare aggiornamenti mirati alle app code e agli asset senza dover aspettare la revisione della store, il che rende molto più facile correggere i flussi di accesso, il trattamento dei callback e gli errori di autenticazione sul lato client quando si verificano in produzione.
