Probabilmente sei qui perché il Sign-In di Google avrebbe dovuto essere 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 dei Clienti di Google sono specifici della piattaforma, e i tipi di applicazione non web spesso non ricevono un segreto del client per progetto
Creare il credenziale sbagliata solo per forzare un segreto nel flusso, di solito si finisce con un setup OAuth rotto che è più difficile da debuggare di quanto dovrebbe essere
- Elenco dei contenuti
- Connettere la tua app al ecosistema di Google
- Dove l'ID del client Google si inserisce nella pratica
- Configurazioni di ID client specifiche per piattaforma
- La sicurezza dei tuoi credenziali Google API
- Risolvere gli errori comuni di ID client
Connettere il tuo app al Google Ecosystem
Molti team si trovano in questo problema allo stesso momento. Hanno bisogno Accedi con Googleo desiderano l'accesso approvato da utenti a qualcosa come Drive o Calendario, e una chiave API improvvisamente non è più sufficiente.
Questo accade perché l'accesso degli utenti e l'accesso delegato passano attraverso OAuth. Google ha bisogno di una via per identificare il tuo appe non solo la API chiamata. Il credenziale che lo fa è il ID del Client Google.
Se lavori 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 del client
- Quali URIs 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 presto. 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 app-side.
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 dai punti di fine 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 qualsiasi flusso in cui la tua 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. __CAPGO_KEEP_0__ chiave
identifica un progetto per certe API chiamate che non coinvolgono l'autorizzazione degli utenti delegati. identifies a project for certain API calls that don’t involve delegated user authorization.
Segreto client è il controparte riservata utilizzato solo nelle flussi e nei tipi di app che possono sicuramente mantenere i 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é è importante distinguere tra questi due concetti?Un solo tocco
, il client ID è il valore che il tuo frontend utilizza per iniziare la mano di scambio 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 lo schema e l'hostname completo.
È 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 sviluppatori di essere nella zona sbagliata. Di solito non lo sono. 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 console giusta
Apre il Cloud Console di Google e seleziona o crea il progetto che gestirà la configurazione delle autorizzazioni. Non disperdere le autorizzazioni 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 > API e servizi
Se il tuo team vede etichette di navigazione diverse, ciò è previsto. Google ha separato la configurazione dell'identità dalla superficie di credenziali del resto API.
Creare la credenziale senza limitarsi
Quando si crea 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. Questa scelta non è estetica. Definisce come l'app viene identificata e quali configurazioni di supporto sono richieste.
For a web app, si prevede di inserire:
- 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 ad esempio 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 propri identificatori di piattaforma. Se si sta 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 desideri confrontare l'interfaccia utente mentre clicchi 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. Puoi tornare alla dashboard per copiare l'ID del client, esaminare le impostazioni e, laddove applicabile, gestire il segreto del client associato a quella credenziale.
La schermata di consenso non è una decorazione. È parte del confine di fiducia. Gli utenti vedono il nome dell'applicazione lì, non il nickname del progetto interno.
Configurazioni di ID del client specifiche della piattaforma
La via più veloce per rompere un setup di accesso Google è supporre 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 riferimento di configurazione della piattaforma.
Perché un'app necessiti di ID del client multipli
La tua prodotto può essere un'app per l'utente, ma è un client OAuth multipli per Google.
A un'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 conservano tutti i credenziali in un ambiente affidabile. Google gestisce questo aspetto fornendo a ogni piattaforma il proprio modello di registrazione dell'app.
Questa separazione è una buona 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 di tipo installato o desktop-style al posto di un flusso del browser basato su un segreto.
Tipi di ID del client Google confrontati
| Tipo di applicazione | Identificatore principale | Fornisce il segreto del client? | Caso d'uso principale |
|---|---|---|---|
| Web | Origini JavaScript autorizzate e indirizzi di reindirizzamento | Di solito sì | Applicazioni del browser e autenticazione OAuth assistita da backend |
| Android | Identità del pacchetto più impronta SHA1 | Di solito no | Accesso Android nativo |
| iOS | Identità del bundle dell'app | Di solito no | Accesso nativo su iPhone e iPad |
| Desktop | Identità dell'app installata | Spesso no | Applicazioni desktop, comprese le flussi native di stile Electron |
Il paradosso del segreto del client per mobile e desktop
Questo è il punto in cui molti tutorial sbagliano.
I 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 questa spiegazione della disallineazione dei credenziali mobiliTuttavia, i tipi di applicazioni non-web, come Android, iOS e applicazioni installate, ricevono spesso un ID client ma non un 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 costringere un segreto nell'implementazione.
Per le Capacitor squadre, ciò si manifesta spesso in uno dei due cattivi schemi:
- L'app avvia un flusso basato su browser utilizzando un client web e poi cerca di comportarsi come un server confidenziale.
- L'app invia un segreto del client da code integrato, che sconfessa l'obiettivo di avere un segreto.
La migliore strategia è 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 all'account Firebase su 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 sola regola, utilizza questa:
seleziona il tipo di client che corrisponde al luogo in cui si esegue __CAPGO_KEEP_0__, non alla forma della credenziale che desideri avere La sicurezza dei tuoi credenziali Google code.
Securing Your Google API Credentials
Segreti del client Google
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 dei 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 perdere. 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 proprio processo di distribuzione.
Ciò che fanno le squadre sicure.
Il team che evita le difficoltà tratta i credenziali OAuth come ogni altro segreto di produzione.
Conserva i segreti dei client web sul backend, iniettali attraverso la gestione dell'ambiente e controlla chi ha accesso alla console. Se stai pulendo il tuo pipeline di rilascio, questa guida sul gestione dei segreti nei pipeline di CI/CD è degna di essere applicata anche alla tua configurazione di autenticazione.
Rivista 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 riguarda solo il nascondimento di un segreto. Si tratta anche di assicurarsi che l'identità dell'applicazione, i target di reindirizzamento e lo schermo di approvazione siano sempre allineati.
Risolvere gli errori comuni dell'ID client.
Gli errori OAuth di Google più comuni derivano 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.
Il modo di risolvere gli errori più comuni
redirect_uri_mismatch
Il tuo app invia 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
Ciò significa spesso che l'app invia il client ID sbagliato, il segreto sbagliato per quel client o mescola le credenziali tra piattaforme. Un esempio comune è un flusso Android o iOS che utilizza accidentalmente le credenziali web in un posto sbagliato.
invalid_request
Questa è una questione ampia, 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 verificare è il tipo di client. La fonte più comune di errore per i developer 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 clientSe 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
Ripeti il controllo dell'impronta 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 legata 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 o meno.
Se il tuo team invia Capacitor o app Electron, i bug di autenticazione sono rari che rimangono 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 i problemi di autenticazione client-side quando si verificano in produzione.
