Rispettare i criteri OAuth 2.0

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Quando è tutto pronto per eseguire il deployment della soluzione implementata oltre l'ambiente di sviluppo per gli utenti della tua app, potrebbero essere necessari ulteriori passaggi per rispettare le norme OAuth 2.0 di Google. In questa guida spieghiamo come rispettare i problemi più comuni riscontrati dagli sviluppatori quando prepari la tua app per la produzione. In questo modo puoi raggiungere il pubblico più ampio possibile con errori limitati.

Utilizza progetti separati per i test e la produzione

I criteri OAuth di Google richiedono progetti separati per i test e la produzione. Alcuni criteri e requisiti si applicano solo alle app in produzione. Potrebbe essere necessario creare e configurare un progetto separato che includa i client OAuth corrispondenti alla versione di produzione dell'app disponibile per tutti gli Account Google.

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

  1. Go to the Google API Console. Click Create project, enter a name, and click Create.
  2. Esamina i client OAuth di questo progetto che potrebbero essere associati al livello di test. Se applicabile, crea client OAuth simili per i client di produzione all'interno del progetto di produzione.
  3. Abilita tutte le API in uso dai tuoi client.
  4. Rivedi la configurazione della schermata di consenso OAuth nel nuovo progetto.

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 sviluppatori. Di seguito sono riportati alcuni esempi:

  • Server di test dei singoli sviluppatori
  • 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 doverti contattare in merito a modifiche ai suoi servizi o a nuove configurazioni richieste per il tuo progetto e i suoi client. Rivedi le schede 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 sulle modifiche richieste al tuo progetto.

Un ruolo contiene un set di autorizzazioni che consente di eseguire azioni specifiche sulle risorse del progetto. Gli editor del progetto hanno le autorizzazioni per le azioni che modificano lo stato, ad esempio la possibilità di apportare modifiche alla schermata di consenso OAuth del progetto. I proprietari del progetto che dispongono di tutte le autorizzazioni di editor possono aggiungere o rimuovere account associati al progetto o eliminarlo. I proprietari del progetto possono anche fornire informazioni sul motivo per cui potrebbero essere impostati i dati di fatturazione. I proprietari del progetto possono configurare le informazioni 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 progetto per garantire l'accesso continuativo al progetto e la manutenzione correlata. Inviamo email a questi account quando vengono inviate notifiche relative al tuo progetto o aggiornamenti ai nostri servizi. Gli amministratori dell'organizzazione Google Cloud devono garantire che un contatto raggiungibile sia associato a ogni progetto dell'organizzazione. Se non abbiamo informazioni di contatto aggiornate per il tuo progetto, potresti perderti messaggi importanti che richiedono un intervento da parte tua.

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 di branding dell'app sono configurate da OAuth Consent Screen page.

Per le app in produzione, le informazioni sul brand definite nella schermata per il consenso OAuth devono essere verificate prima di essere mostrate agli utenti. Gli utenti potrebbero essere più propensi a concedere l'accesso alla tua app dopo aver completato la verifica del brand. Le informazioni di base dell'applicazione, che includono il nome, la home page, i termini di servizio e le norme sulla privacy dell'app, vengono mostrate agli utenti nella schermata di concessione, quando controllano le autorizzazioni esistenti o agli amministratori di Google Workspace che ne controllano l'utilizzo 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 ingannevole la propria identità o tentano di ingannare gli utenti.

Richiedi solo gli ambiti necessari

Durante lo sviluppo della tua applicazione, potresti aver utilizzato un ambito di esempio fornito dall'API per creare un proof of concept all'interno della tua applicazione, per scoprire di più sulle caratteristiche e sulla funzionalità dell'API. Questi ambiti di esempio richiedono spesso più informazioni rispetto all'implementazione finale della tua app, perché offrono una copertura completa di tutte le possibili azioni per un'API specifica. Ad esempio, l'ambito di esempio potrebbe richiedere autorizzazioni di lettura, scrittura ed eliminazione, mentre l'applicazione richiede solo autorizzazioni di lettura. Richiedi le autorizzazioni pertinenti limitate alle informazioni fondamentali necessarie per implementare l'applicazione.

Consulta la documentazione di riferimento per gli endpoint API chiamati dalla tua app e prendi nota degli ambiti richiesti per accedere ai dati pertinenti necessari per la tua app. Consulta le guide di autorizzazione offerte dall'API e descrivi i relativi ambiti in modo più dettagliato per includere l'utilizzo più comune. Scegli il livello di accesso ai dati minimo indispensabile all'applicazione per alimentare le funzionalità correlate.

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

Inviare app di produzione che utilizzano ambiti sensibili o con restrizioni per la verifica

Alcuni ambiti sono classificati come"sensibili"o"con restrizioni"e non possono essere utilizzati nelle app per la produzione senza revisione. Inserisci tutti gli ambiti che la tua app di produzione utilizza nella sua configurazione della schermata per il consenso OAuth. Se la tua app in produzione utilizza ambiti sensibili o con restrizioni, devi inviare l'utilizzo di tali ambiti per la verifica prima di includere gli ambiti in una richiesta di autorizzazione.

Utilizza solo i domini di tua proprietà

La procedura di verifica della schermata di consenso OAuth di Google richiede la verifica di tutti i domini associati alla home page del tuo progetto, alle norme sulla privacy, ai Termini di servizio, agli URI di reindirizzamento autorizzati o alle origini JavaScript autorizzate. Controlla l'elenco dei domini utilizzati dalla tua app, riepilogati nella sezione Domini autorizzati dell'editor della schermata per il consenso OAuth e identifica eventuali domini che non sono di tua proprietà e che pertanto non potrebbero essere verificati. Per verificare la proprietà dei domini autorizzati del tuo progetto, utilizza Google Search Console. Utilizza un Account Google associato al tuo API Console progetto come Proprietario o Editor.

Se il tuo progetto utilizza un provider di servizi con un dominio condiviso comune, ti consigliamo di abilitare le configurazioni che consentirebbero l'utilizzo del tuo dominio. Alcuni provider offrono la mappatura dei loro servizi a un sottodominio di un dominio che già possiedi.

Ospita una home page per le app in produzione

Ogni app in 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 scoprire di più sulle caratteristiche e funzionalità offerte dall'app. Gli utenti esistenti potrebbero esaminare il proprio elenco di autorizzazioni esistenti e visitare la home page dell'app per ricordarti di continuare a utilizzare l'offerta.

La home page della tua applicazione deve includere una descrizione della funzionalità dell'app, link alle norme sulla privacy e termini di servizio facoltativi. La home page deve esistere in un dominio verificato di tua proprietà.

Utilizza URI di reindirizzamento sicuri e origini JavaScript

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

Valuta quali applicazioni e script di terze parti potrebbero avere accesso ai token e ad altre credenziali utente che tornano sulla tua pagina. Limita l'accesso ai dati sensibili con posizioni dell'URI di reindirizzamento che sono limitate alla verifica e all'archiviazione dei dati del token.

Passaggi successivi

Dopo aver verificato che l'app è conforme alle norme OAuth 2.0 in questa pagina, consulta l'articolo Inviare per la verifica del brand per i dettagli sulla procedura di verifica.