Rispettare i criteri OAuth 2.0

Questa guida descrive come rispettare le norme per risolvere i problemi più comuni degli sviluppatori riscontrati durante la preparazione dell'app per la produzione.

Panoramica

Quando è tutto pronto per implementare la soluzione oltre l'ambiente di sviluppo per gli utenti dell'app, potresti dover eseguire passaggi aggiuntivi per rispettare le norme OAuth 2.0 di Google. In questa guida, descriviamo come rispettare le norme per risolvere i problemi più comuni degli sviluppatori riscontrati durante la preparazione dell'app per la produzione. In questo modo, puoi raggiungere il pubblico più ampio possibile con errori limitati.

Utilizzare progetti separati per i test e la produzione

Le norme OAuth di Google richiedono progetti separati per i test e la produzione. Alcune norme e alcuni requisiti si applicano solo alle app di produzione. Potresti dover creare e configurare un progetto separato che includa i client OAuth corrispondenti alla versione di produzione della tua app disponibile per tutti gli Account Google.

I client OAuth di Google utilizzati in produzione contribuiscono a fornire un ambiente di raccolta e archiviazione dei dati più stabile, prevedibile e sicuro rispetto a client OAuth simili che testano o eseguono il debug della stessa applicazione. Il progetto di produzione può essere inviato per la verifica e quindi essere soggetto a requisiti aggiuntivi per ambiti API specifici, che potrebbero includere valutazioni di sicurezza di terze parti.

  1. Vai alla console dell'API di Google. Fai clic su Crea progetto, inserisci un nome e fai clic su Crea.
  2. Esamina i client OAuth in questo progetto che potrebbero essere associati al tuo livello di test. Se applicabile, crea client OAuth simili per i client di produzione all'interno del progetto di produzione.
  3. Attiva le API in uso dai tuoi client.
  4. Esamina la configurazione della schermata per il consenso OAuth per il nuovo progetto nella pagina Branding di Cloud Console.

I client OAuth di Google utilizzati in produzione non devono contenere ambienti di test, URI di reindirizzamento o origini JavaScript disponibili solo per te o per il tuo team di sviluppo. Ecco alcuni esempi:

  • I server di test dei singoli sviluppatori
  • Le versioni di test o pre-release della tua app

Mantenere un elenco di contatti pertinenti per il progetto

Google e le singole API che abiliti potrebbero dover contattarti in merito a modifiche ai propri servizi o a nuove configurazioni richieste per il tuo progetto e i relativi client. Esamina gli elenchi IAM del tuo progetto per assicurarti che le persone pertinenti del tuo team abbiano accesso alla modifica o alla visualizzazione della configurazione del progetto. Questi account potrebbero anche ricevere email relative alle modifiche richieste al tuo progetto.

Un ruolo contiene un insieme di autorizzazioni che ti consentono di eseguire azioni specifiche sulle risorse del progetto. Gli editor di progetti hanno autorizzazioni per le azioni che modificano lo stato, ad esempio la possibilità di apportare modifiche alla schermata per il consenso OAuth del progetto. I proprietari del progetto che dispongono di tutte le autorizzazioni di editor possono aggiungere o rimuovere gli account associati al progetto oppure eliminare il progetto. I Project Owner possono anche fornire il contesto per cui potrebbero essere impostati i dati di fatturazione. I proprietari del progetto possono configurare i dati di fatturazione per un progetto che utilizza API a pagamento.

I proprietari e gli editor del progetto devono essere sempre aggiornati. Puoi aggiungere più account pertinenti al tuo progetto per garantire l'accesso continuo al progetto e alla relativa manutenzione. Inviamo email a questi account quando sono presenti notifiche relative al tuo progetto o aggiornamenti ai nostri servizi. Gli amministratori dell'organizzazione Google Cloud devono assicurarsi che a ogni progetto della loro organizzazione sia associato un contatto raggiungibile. Se non disponiamo di informazioni di contatto aggiornate per il tuo progetto, potresti perdere messaggi importanti che richiedono la tua azione.

Rappresentare con precisione la tua identità

Fornisci un nome dell'app valido e, facoltativamente, un logo da mostrare agli utenti. Queste informazioni sul brand devono rappresentare con precisione l'identità della tua applicazione. Le informazioni sul branding dell'app vengono configurate dalla pagina Branding OAuth Branding page.

Per le app di produzione, le informazioni sul brand definite nella schermata per il consenso OAuth devono essere verificate prima di essere visualizzate dagli utenti. Gli utenti potrebbero essere più propensi a concedere l'accesso alla tua app dopo che ha completato la verifica del brand. Le informazioni di base sull'applicazione, che includono il nome dell'app, la home page, i Termini di servizio e le norme sulla privacy, vengono mostrate agli utenti nella schermata di concessione, quando esaminano le concessioni esistenti o agli amministratori di Google Workspace che esaminano l'utilizzo dell'app da parte della loro organizzazione.

Google può revocare o sospendere l'accesso ai servizi API di Google e ad altri prodotti e servizi Google per le app che rappresentano in modo errato la propria identità o tentano di ingannare gli utenti.

Richiedere solo gli ambiti necessari

Durante lo sviluppo dell'applicazione, potresti aver utilizzato un ambito di esempio fornito dall'API per creare una prova di concetto all'interno dell'applicazione per saperne di più sulle funzionalità dell'API. Questi ambiti di esempio spesso richiedono più informazioni di quelle necessarie per l'implementazione finale dell'app, perché forniscono una copertura completa di tutte le possibili azioni per una determinata API. Ad esempio, l'ambito di esempio potrebbe richiedere le autorizzazioni di lettura, scrittura ed eliminazione, mentre l'applicazione richiede solo le autorizzazioni di lettura. Richiedi le autorizzazioni pertinenti limitate alle informazioni essenziali necessarie per implementare l'applicazione.

Esamina la documentazione di riferimento per gli endpoint API chiamati dalla tua app e prendi nota degli ambiti richiesti per accedere ai dati pertinenti di cui ha bisogno la tua app. Esamina le guide all'autorizzazione offerte dall'API e descrivi gli ambiti in modo più dettagliato per includere l'utilizzo più comune. Scegli l'accesso ai dati più limitato di cui la tua applicazione ha bisogno per alimentare le funzionalità correlate.

Per ulteriori informazioni su questo requisito, consulta la sezione Richiedere solo gli ambiti necessari delle norme OAuth 2.0, insieme alla sezione Richiedere le autorizzazioni pertinenti delle norme relative ai dati utente dei servizi API di Google.

Inviare per la verifica le app di produzione che utilizzano ambiti non sensibili o senza restrizioni

Accedi con Google non richiede ambiti sensibili e con restrizioni durante l'autenticazione di un utente. Se la tua applicazione utilizza Accedi con Google solo per l'autenticazione, devi inviarla per la verifica del brand. Puoi inviare la richiesta di verifica in console Google Cloud dalla pagina Branding. Questa verifica è necessaria per visualizzare gli elementi di branding dell'app, inclusi nome, logo, norme sulla privacy, Termini di servizio e ambiti, nella schermata per il consenso.

Ti consigliamo vivamente di rispettare le linee guida ufficiali per il branding per il posizionamento del pulsante Accedi.

Utilizzare solo i domini di tua proprietà

La procedura di verifica della schermata per il consenso OAuth di Google richiede la verifica di tutti i domini associati alla home page, alle norme sulla privacy, ai Termini di servizio, agli URI di reindirizzamento autorizzati o alle origini JavaScript autorizzate del tuo progetto. Esamina l'elenco dei domini in uso dalla tua app, riepilogati nella sezione Domini autorizzati dell'editor della schermata per il consenso OAuth, e identifica i domini di cui non sei proprietario e che quindi non potresti verificare. Per verificare la proprietà dei domini autorizzati del tuo progetto, utilizza la Google Search Console. Utilizza un Account Google associato al tuo progetto della console dell'API come proprietario o editor.

Se il tuo progetto utilizza un fornitore di servizi con un dominio comune e condiviso, ti consigliamo di abilitare le configurazioni che consentono l'utilizzo del tuo dominio. Alcuni provider offrono di mappare i propri servizi a un sottodominio di un dominio di cui sei già proprietario.

Ospitare una home page per le app di produzione

Ogni app di produzione che utilizza OAuth 2.0 deve avere una home page accessibile pubblicamente. I potenziali utenti della tua app potrebbero visitare la home page per saperne di più sulle funzionalità offerte dall'app. Gli utenti esistenti potrebbero esaminare l'elenco delle concessioni esistenti e visitare la home page della tua app come promemoria del loro utilizzo continuativo della tua offerta.

La home page dell'applicazione deve includere una descrizione delle funzionalità dell'app, nonché link alle norme sulla privacy e ai Termini di servizio facoltativi. La home page deve esistere su un dominio verificato di tua proprietà.

Utilizzare URI di reindirizzamento e origini JavaScript sicuri

I client OAuth 2.0 per le app web devono proteggere i propri dati utilizzando URI di reindirizzamento e origini JavaScript HTTPS, non HTTP semplici. Google può rifiutare le richieste OAuth che non provengono da o non vengono risolte in un contesto sicuro.

Valuta quali applicazioni e script di terze parti potrebbero avere accesso ai token e ad altre credenziali utente che vengono restituite alla tua pagina. Limita l'accesso ai dati sensibili con località URI di reindirizzamento limitate alla verifica e all'archiviazione dei dati dei token.

Passaggi successivi

Dopo aver verificato che la tua app rispetta le norme OAuth 2.0 in questa pagina, consulta Inviare per la verifica del brand per i dettagli sulla procedura di verifica.