Rispettare i criteri OAuth 2.0

Questa guida illustra come garantire la conformità ai problemi più comuni degli sviluppatori riscontrati durante la preparazione dell'app per la produzione.

Panoramica

Quando è tutto pronto per eseguire il deployment della soluzione implementata oltre l'ambiente di sviluppo per gli utenti della tua app, potresti dover eseguire ulteriori passaggi per rispettare le norme di Google OAuth 2.0. In questa guida, illustriamo come garantire la conformità ai 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 un numero limitato di errori.

Utilizza progetti separati per i test e la produzione

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

I client Google OAuth 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 tuo progetto di produzione può essere inviato per la verifica ed essere quindi soggetto a requisiti aggiuntivi per ambiti API specifici, che potrebbero includere valutazioni della 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 di 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. Abilita le API utilizzate dai tuoi client.
  4. Esamina la configurazione della schermata per il consenso OAuth per il nuovo progetto nella pagina Branding della console Cloud.

I client Google OAuth 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. Di seguito sono riportati alcuni esempi:

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

Mantieni un elenco di contatti pertinenti per il progetto

Google e le singole API che abiliti potrebbero dover contattarti in merito a modifiche ai relativi servizi o a nuove configurazioni richieste per il tuo progetto e i relativi client. Esamina gli elenchi IAM del progetto per assicurarti che le persone pertinenti del tuo team abbiano accesso per modificare o visualizzare la 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 progetto dispongono delle autorizzazioni per le azioni che modificano lo stato, ad esempio la possibilità di apportare modifiche alla schermata per il consenso OAuth del progetto. I Project Owner che dispongono di tutte le autorizzazioni di Editor possono aggiungere o rimuovere gli account associati al progetto o eliminare il progetto. I Project Owner possono anche fornire il contesto per cui potrebbero essere impostati i dati di fatturazione. I Project Owner possono configurare i dati di fatturazione per un progetto che utilizza API a pagamento.

I Project Owner e gli Editor devono essere 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 propria organizzazione sia associato un contatto raggiungibile. Se non disponiamo di dati di contatto aggiornati per il tuo progetto, potresti perderti messaggi importanti che richiedono la tua azione.

Rappresenta 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.

Per le app di 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 che questa ha completato la verifica del brand. Le informazioni di base sull'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 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 forniscono informazioni false sulla propria identità o tentano di ingannare gli utenti.

Richiedi solo gli ambiti di cui hai bisogno

Durante lo sviluppo della tua applicazione, potresti aver utilizzato un ambito di esempio fornito dall'API per creare una proof of concept all'interno della tua applicazione per scoprire di più sulle caratteristiche e sulle funzionalità dell'API. Questi ambiti di esempio spesso richiedono più informazioni di quelle necessarie per l'implementazione finale della tua app, perché forniscono una copertura completa di tutte le azioni possibili per una determinata API. Ad esempio, l'ambito di esempio potrebbe richiedere autorizzazioni in lettura, scrittura ed eliminazione, mentre la tua applicazione richiede solo autorizzazioni in lettura. Richiedi 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 l'app ha bisogno. Esamina le guide all'autorizzazione offerte dall'API e descrivi i relativi 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 supportare le funzionalità correlate.

Per saperne di più su questo requisito, leggi la sezione Richiedi solo gli ambiti di cui hai bisogno delle norme OAuth 2.0, nonché la sezione Richiedi 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 non con restrizioni

Accedi con Google non richiede ambiti sensibili e con limitazioni 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 nella console Google Cloud dalla pagina Branding. Questa verifica è necessaria per visualizzare gli elementi distintivi del brand dell'app, tra cui nome, logo, norme sulla privacy, Termini di servizio e ambiti, nella schermata per il consenso.

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

Utilizza solo 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 progetto. Esamina l'elenco dei domini utilizzati 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, di conseguenza, non potresti verificare. Per verificare la proprietà dei domini autorizzati del tuo progetto, utilizza Google Search Console. Utilizza un Account Google associato al tuo progetto della console API come proprietario o editor.

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

Ospitare una home page per le app in 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 scoprire di più sulle caratteristiche e sulle funzionalità offerte dall'app. Gli utenti esistenti potrebbero esaminare il loro elenco di concessioni esistenti e visitare la home page della tua app per ricordarsi di continuare a utilizzare la tua offerta.

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

Utilizza 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 HTTPS e origini JavaScript, non HTTP semplice. Google può rifiutare le richieste OAuth che non provengono da un contesto sicuro 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 posizioni degli URI di reindirizzamento limitate alla verifica e all'archiviazione dei dati dei token.

Passaggi successivi

Dopo aver verificato che la tua app è conforme alle policy OAuth 2.0 riportate in questa pagina, consulta Invia per la verifica del brand per informazioni dettagliate sulla procedura di verifica.