Verifica dell'ambito sensibile

Se la tua app chiede l'autorizzazione a utilizzare le API di Google per accedere ai dati degli utenti Google, potresti dover completare una procedura di verifica prima di rendere la tua app disponibile pubblicamente per la prima volta.

Se questo requisito si applica alla tua app dipende principalmente da due fattori:

  1. Il tipo di dati utente a cui accedi: informazioni del profilo pubblico, voci del calendario, file in Drive, determinati dati sul fitness e così via.
  2. Il livello di accesso di cui hai bisogno: di sola lettura, di lettura e scrittura e così via.

Quando utilizzi OAuth 2.0 per ottenere l'autorizzazione da un Account Google ad accedere ai suoi dati, utilizzi stringhe chiamate ambiti per specificare il tipo di dati a cui vuoi accedere per suo conto. Se la tua app richiede ambiti classificati come sensibili o con restrizioni, probabilmente devi completare la procedura di verifica, a meno che l'utilizzo della tua app non rientri in un'eccezione.

Esempi di ambiti sensibili includono la lettura degli eventi memorizzati in Google Calendar, la memorizzazione di un nuovo contatto in Contatti Google o l'eliminazione di un video di YouTube. Per ulteriori informazioni sugli ambiti disponibili e sulle relative classificazioni, consulta la documentazione di riferimento degli endpoint API chiamati dalla tua app e qualsiasi guida all'autorizzazione correlata pubblicata per l'API.

Devi richiedere gli ambiti che richiedono la quantità minima di accesso ai dati utente necessaria per fornire la funzionalità. Ad esempio, un'app che legge solo i dati non deve richiedere l'accesso per leggere, scrivere ed eliminare i contenuti quando è disponibile un ambito più ristretto per l'API e i relativi endpoint. I dati che ricevi da un'API di Google devono essere utilizzati solo in conformità alle norme dell'API e nel modo in cui li presenti ai tuoi utenti nelle azioni dell'app e nelle norme sulla privacy.

Assicurati di tenere conto del tempo necessario per completare la verifica nel piano di lancio della tua app o di eventuali nuove funzionalità che richiedono un nuovo ambito. Il completamento della procedura di verifica degli ambiti sensibili può richiedere fino a 10 giorni. Tieni presente che la tua app potrebbe essere idonea a completare la verifica del brand come sottoinsieme della richiesta di verifica degli ambiti sensibili.

Informazioni sugli ambiti sensibili

Gli ambiti sensibili richiedono la revisione da parte di Google prima che qualsiasi Account Google possa concedere l'accesso. Gli amministratori dell'organizzazione Google Workspace potrebbero limitare l'accesso agli ambiti sensibili per impedire l'accesso da parte degli ID client OAuth che l'organizzazione non contrassegna esplicitamente come attendibili.

Informazioni sull'utilizzo degli ambiti

  • Esamina gli ambiti utilizzati dalla tua app o che vuoi utilizzare. Per trovare l'utilizzo degli ambiti esistenti, esamina il codice sorgente dell'app per verificare la presenza di ambiti inviati con le richieste di autorizzazione.
  • Assicurati che ogni ambito richiesto sia necessario per le azioni previste della funzionalità dell'app e che utilizzi il privilegio minimo necessario per fornire la funzionalità. Un'API di Google in genere ha documentazione di riferimento nella pagina Google Developers del prodotto per i suoi endpoint che include l'ambito richiesto per chiamare l' endpoint o proprietà specifiche al suo interno. Per ulteriori informazioni sugli ambiti di accesso necessari per gli endpoint API chiamati dalla tua app, leggi la documentazione di riferimento di questi endpoint.
  • I dati che ricevi da un'API di Google devono essere utilizzati solo in conformità alle norme di tale API e nel modo in cui li presenti ai tuoi utenti nelle azioni dell'app e nelle norme sulla privacy.
  • Consulta la documentazione dell'API per saperne di più su ogni ambito, incluso il relativo stato potenziale
  • Dichiara tutti gli ambiti utilizzati dalla tua app nella pagina Accesso ai dati di Cloud Console. Gli ambiti specificati vengono raggruppati in categorie sensibili o con restrizioni per evidenziare eventuali verifiche aggiuntive richieste.
  • Trova l'ambito migliore che corrisponda ai dati utilizzati dall'integrazione, comprendi il suo utilizzo, riconferma che tutto funzioni ancora in un ambiente di test e poi preparati a inviare la richiesta di verifica.
Una tabella mostra il nome di un'API, uno dei suoi ambiti sensibili e una descrizione di ciò che copre l'ambito.
Figura 1. Un esempio di ambito sensibile mostrato nella pagina degli ambiti di configurazione della schermata per il consenso OAuth.

Passaggi per prepararsi alla verifica

Tutte le app che utilizzano le API di Google per richiedere l'accesso ai dati devono eseguire i seguenti passaggi per completare la verifica del brand:

  1. Verifica che la tua app non rientri in nessuno dei casi d'uso descritti nella sezione Eccezioni ai requisiti di verifica.
  2. Assicurati che la tua app sia conforme ai requisiti di branding delle API o del prodotto associati. Ad esempio, consulta le linee guida per il branding degli ambiti di accesso con Google.
  3. Verifica la proprietà dei dominiautorizzati del tuo progetto inGoogle Search Console. Utilizza un Account Google associato al tuo progetto della console API come proprietario o editor.
  4. Assicurati che tutte le informazioni sul branding nella schermata per il consenso OAuth, come il nome dell'app, l'email di assistenza , l'URI della home page, l'URI delle norme sulla privacy e così via, rappresentino accuratamente l'identità dell'app.

Requisiti della home page dell'applicazione

Assicurati che la tua home page soddisfi i seguenti requisiti:

  • La home page deve essere accessibile pubblicamente e non solo agli utenti che hanno eseguito l'accesso al tuo sito.
  • La pertinenza della home page rispetto all'app in corso di revisione deve essere chiara.
  • I link alla scheda dell'app sul Google Play Store o alla sua pagina Facebook non sono considerati valide home page dell'applicazione.

Requisiti del link alle norme sulla privacy dell'applicazione

Assicurati che le norme sulla privacy della tua app soddisfino i seguenti requisiti:

  • Le norme sulla privacy devono essere visibili agli utenti, ospitate nello stesso dominio della home page dell'applicazione e collegate alla schermata per il consenso OAuth della console API di Google. Tieni presente che la home page deve includere una descrizione delle funzionalità dell'app, nonché link alle norme sulla privacy e ai termini di servizio facoltativi.
  • Le norme sulla privacy devono indicare la modalità di accesso, utilizzo, archiviazione o condivisione dei dati degli utenti Google da parte dell'applicazione. Devi limitare l'utilizzo dei dati degli utenti Google alle prassi indicate nelle norme sulla privacy pubblicate.

Come richiedere la verifica del brand della tua app

Un progetto console Google Cloud organizza tutte le risorse di console Cloud. Un progetto è composto da un insieme di Account Google associati che hanno l'autorizzazione a eseguire operazioni sul progetto, un insieme di API abilitate e impostazioni di fatturazione, autenticazione e monitoraggio per queste API. Ad esempio, un progetto può contenere uno o più client OAuth, configurare le API per l'utilizzo da parte di questi client e configurare una schermata per il consenso OAuth mostrata agli utenti prima che autorizzino l'accesso alla tua app.

Se uno dei tuoi client OAuth non è pronto per la produzione, ti consigliamo di eliminarlo da il progetto che richiede la verifica. Puoi farlo nella pagina Client.

Per inviare la richiesta di verifica:

  1. Assicurati che la tua app sia conforme ai Termini di servizio delle API di Google e alle Norme relative ai dati utente dei servizi API di Google.
  2. Mantieni aggiornati i ruoli di proprietario ed editor degli account associati al tuo progetto, nonché l'email di assistenza utenti e i dati di contatto dello sviluppatore della schermata per il consenso OAuth, in Cloud Console. In questo modo, i membri del team corretti vengono informati di eventuali nuovi requisiti.
  3. Vai alla pagina Branding OAuth di Cloud Console Branding page.
  4. Fai clic sul pulsante Selettore progetto.

  5. Nella finestra di dialogo Seleziona da visualizzata, seleziona il tuo progetto. Se non riesci a trovare il tuo progetto, ma conosci l'ID progetto, puoi creare un URL nel browser nel seguente formato:

    https://console.developers.google.com/auth/branding?project=[PROJECT_ID]

    Sostituisci [PROJECT_ID] con l'ID progetto che vuoi utilizzare.

  6. Nella pagina Branding, fornisci le informazioni sul branding della tua app, inclusi il nome dell'app, il logo, i dati di contatto dello sviluppatore e i link pertinenti. Le modifiche apportate vengono salvate come Branding bozza.
  7. Fai clic sul pulsante Verifica branding per avviare la procedura di valutazione processo. La revisione automatizzata in genere viene completata in pochi minuti.
  8. Una volta completata la valutazione, esamina lo stato. Se la procedura va a buon fine, lo stato diventa Pronto per la pubblicazione. Se la verifica automatica non va a buon fine, puoi visualizzare i problemi rilevati e correggerli o richiedere una revisione manuale.
  9. Fai clic sul pulsante Pubblica branding per rendere attivo il nuovo branding live.

  10. Se la tua app richiede anche la verifica degli ambiti sensibili o con restrizioni, vai al Centro di verifica OAuth per monitorare lo Stato di accesso ai dati e fornire eventuali informazioni aggiuntive richieste, ad esempio un video dimostrativo. Tieni presente che devi avere uno stato di branding pubblicato prima di poter richiedere la verifica dell'accesso ai dati.

  11. Utilizza il pulsante Aggiungi o rimuovi ambiti per dichiarare tutti gli ambiti richiesti dalla tua app. Un insieme iniziale di ambiti necessari per l'accesso con Google viene precompilato nella sezione Ambiti non sensibili. Gli ambiti aggiunti vengono classificati come non sensibili, sensitive, or <a href="/identity/protocols/oauth2/production-readiness/restricted-scope-verification"

    restricted.

  12. Fornisci fino a tre link a qualsiasi documentazione pertinente per le funzionalità correlate della tua app.

  13. Fornisci eventuali informazioni aggiuntive richieste sulla tua app nei passaggi successivi.

    1. Prepare a detailed justification for each requested sensitive scope, as well as an explanation for why a narrower scope isn't sufficient. For example: "My app will use https://www.googleapis.com/auth/calendar to show a user's Google calendar data on the scheduling screen of my app. This lets users manage their schedules through my app and sync the changes with their Google calendar."

    2. Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set its Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.

      1. Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
      2. Show that the OAuth consent screen correctly displays the App Name.
      3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
      4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive scope that you request.

Dopo aver pubblicato il branding o inviato una richiesta di accesso ai dati, il team Trust & Safety di Google potrebbe contattarti via email per richiedere ulteriori informazioni o indicarti i passaggi da completare. Controlla gli indirizzi email nella sezione Dati di contatto dello sviluppatore e l'email di assistenza della schermata per il consenso OAuth per verificare la presenza di richieste di informazioni aggiuntive. Puoi anche visualizzare le pagine Branding o Centro di verifica del tuo progetto per confermare lo stato attuale della revisione del progetto, incluso se la procedura di revisione è in pausa in attesa di una tua risposta.

Eccezioni ai requisiti di verifica

Se la tua app verrà utilizzata in uno degli scenari descritti nelle sezioni seguenti, non devi inviarla per la revisione.

Utilizzo personale

Un caso d'uso è se sei l'unico utente della tua app o se la tua app viene utilizzata solo da pochi utenti, che conosci personalmente. Tu e il numero limitato di utenti potreste sentirvi a vostro agio nell'avanzare nella schermata dell'app non verificata e nel concedere ai vostri account personali l'accesso alla vostra app.

Progetti utilizzati nei livelli di sviluppo, test o gestione temporanea

Per rispettare le Norme relative a OAuth 2.0 di Google, ti consigliamo di avere progetti diversi per gli ambienti di test e di produzione. Ti consigliamo di inviare la tua app per la verifica solo se vuoi renderla disponibile a qualsiasi utente con un Account Google. Pertanto, se la tua app è in fase di sviluppo, test o gestione temporanea, la verifica non è obbligatoria.

Se la tua app è in fase di sviluppo o test, puoi lasciare lo stato di pubblicazione nell'impostazione predefinita Test. Questa impostazione indica che la tua app è ancora in fase di sviluppo ed è solo disponibile per gli utenti che aggiungi all'elenco degli utenti di test. Devi gestire l'elenco degli Account Google coinvolti nello sviluppo o nel test della tua app.

Messaggio di avviso che indica che Google non ha verificato un'app in fase di test.
Figura 2. Schermata di avviso per i tester

Solo dati di proprietà del servizio

Se la tua app utilizza un service account per accedere solo ai propri dati e non accede a nessun dato utente (collegato a un Account Google), non devi inviarla per la verifica.

Per capire cosa sono i service accounts, consulta Service accounts nella documentazione di Google Cloud. Per istruzioni su come utilizzare un service account, consulta Utilizzo di OAuth 2.0 per applicazioni da server a server.

Solo per uso interno

Ciò significa che l'app viene utilizzata solo dalle persone della tua organizzazione Google Workspace o Cloud Identity organizzazione. Il progetto deve essere di proprietà dell'organizzazione e la relativa schermata per il consenso OAuth deve essere configurata per un tipo di utenteinterno. In questo caso, la tua app potrebbe richiedere l'approvazione di un amministratore dell'organizzazione. Per ulteriori informazioni, consulta Considerazioni aggiuntive per Google Workspace.

Installazione a livello di dominio

Se prevedi che la tua app sia destinata solo agli utenti di un'organizzazione Google Workspace o Cloud Identity e utilizzi sempre l'installazione a livello di dominio, la tua app non richiederà la verifica del brand. Tuttavia, se la tua app utilizza ambiti con restrizioni o sensibili, la verifica dell'app è necessaria. Questo perché un'installazione a livello di dominio consente a un amministratore di dominio di concedere alle applicazioni interne e di terze parti l'accesso ai dati dei tuoi utenti. Solo gli account degli amministratori dell'organizzazione possono aggiungere l'app a una lista consentita per l'utilizzo all'interno dei loro domini.

Scopri come rendere la tua app un'installazione a livello di dominio nella domanda frequente La mia applicazione ha utenti con account aziendali di un altro dominio Google Workspace.