Best practice per sviluppatori in seguito ai miglioramenti ai controlli dell'accesso alle app di terze parti di Google Workspace for Education

Google ha introdotto le impostazioni di Controllo accesso app per consentire agli amministratori di Google Workspace for Education di controllare in che modo le app di terze parti accedono ai dati di Google delle loro organizzazioni quando gli utenti accedono utilizzando i propri account Google Workspace for Education. Sebbene non siano richieste azioni da parte degli sviluppatori di app di terze parti, di seguito sono riportate alcune best practice che altri sviluppatori hanno trovato utili.

Utilizza OAuth incrementale

Puoi utilizzare l'autorizzazione incrementale per richiedere inizialmente solo gli ambiti necessari per avviare l'app, quindi richiedere ambiti aggiuntivi man mano che sono necessarie nuove autorizzazioni. Il contesto dell'app identifica quindi il motivo della richiesta all'utente.

Al momento dell'accesso, la tua app richiede ambiti di base come il profilo dell'ambito di accesso e altri ambiti iniziali necessari per il funzionamento. In seguito, quando l'utente vuole eseguire un'azione che richiede ambiti aggiuntivi, la tua app li richiede e l'utente autorizza solo i nuovi ambiti da una schermata di consenso.

Quando crei un componente aggiuntivo di Google Classroom, devi seguire le linee guida di Google Workspace Marketplace per fornire un elenco completo degli ambiti OAuth richiesti dalla tua app. Questo è necessario affinché un amministratore comprenda a quali ambiti viene chiesto il consenso a un utente di un dominio.

Assicurati che tutte le app siano verificate OAuth

Tutte le app che accedono alle API di Google devono verificare di rappresentare con precisione la propria identità e il proprio intento come specificato dalle norme relative ai dati utente dei servizi API di Google. Se gestisci più app che utilizzano le API di Google, assicurati che ciascuna sia stata verificata. Gli amministratori possono vedere tutti gli ID client OAuth associati al tuo brand verificato. Per aiutare gli amministratori a evitare di configurare ID client OAuth errati, utilizza progetti Google Cloud separati per test e produzione e elimina tutti gli ID client OAuth non in uso.

La verifica API OAuth è un processo che Google Cloud Platform utilizza per garantire che le app che richiedono ambiti sensibili o con restrizioni siano sicure e conformi. La procedura di verifica contribuisce a proteggere gli utenti e i dati di Google Cloud da accessi non autorizzati.

Le app che richiedono ambiti sensibili o con limitazioni devono essere conformi alle Norme sui dati utente: servizi API di Google. Queste norme richiedono alle app di proteggere i dati utente e di utilizzarli solo per le finalità autorizzate dall'utente. Inoltre, le app potrebbero dover essere sottoposte a una valutazione di sicurezza indipendente per verificare che soddisfino i requisiti di sicurezza di Google Cloud.

Tieni presente che il completamento della procedura di verifica dell'API OAuth può richiedere diverse settimane. Una volta verificata l'app, puoi richiedere gli ambiti sensibili o con limitazioni di cui hai bisogno.

Per ulteriori dettagli, consulta le domande frequenti sulla verifica dell'API OAuth.

Gestire più ID client OAuth

Un progetto Google Cloud potrebbe avere più ID client OAuth, il che potrebbe richiedere all'amministratore di un dominio di configurare il tuo accesso più volte.

Garantire l'accuratezza degli ID client OAuth

Rivolgiti al tuo team di sviluppo per sapere quali ID client OAuth vengono utilizzati per l'integrazione con OAuth di Google. Utilizzare due diversi progetti Google Cloud per i test e la produzione, in modo che gli amministratori possano capire quali ID client OAuth configurare. Elimina gli ID client ritirati o obsoleti dai progetti di produzione.

Caricamento di un file CSV

Se hai più ID cliente, ti consigliamo di utilizzare l'opzione di caricamento collettivo CSV per aiutare gli amministratori a configurare rapidamente tutte le tue app.

I campi sono:

Campo Obbligatorio Note
Nome app No Inserisci il nome dell'app. Le modifiche apportate al nome dell'app nel file CSV non vengono aggiornate nella Console di amministrazione.
Tipo Uno dei valori Applicazione web, Android o iOS.
ID Per le app web, inserisci l'ID client OAuth emesso per l'applicazione.

Per le app per Android e iOS, inserisci l'ID client OAuth o l'ID pacchetto o bundle utilizzato dall'app in Google Play o nell'Apple App Store.
Unità organizzativa Da compilare dal cliente.

Inserisci una barra ('/') per applicare l'impostazione di accesso alle app all'intero dominio. Per applicare le impostazioni di accesso a unità organizzative specifiche, aggiungi una riga al foglio di lavoro per ogni unità organizzativa, ripetendo il nome, il tipo e l'ID dell'app. (ad esempio, "/org_unit_1/sub_unit_1").
Accesso Uno di attendibili, bloccati o limitati.

Errori OAuth

Con questi nuovi controlli dell'amministratore sono stati introdotti due messaggi di errore.

  • Errore 400: access_not_configured: viene visualizzato quando una connessione OAuth viene rifiutata perché l'app non è stata configurata.
  • Errore 400: admin_policy_enforced: viene visualizzato quando una connessione OAuth viene rifiutata perché l'amministratore ha bloccato la tua applicazione.

Utenti identificati come minori di 18 anni

Gli amministratori possono gestire l'accesso alle app di terze parti non configurate per gli utenti identificati come minori di 18 anni. Se un utente riscontra l'errore "Accesso bloccato: l'amministratore del tuo istituto deve esaminare [nome dell'app]", deve richiedere l'accesso dal messaggio di errore. L'amministratore potrà così esaminare l'applicazione di terze parti. Gli amministratori possono decidere se consentire o bloccare le applicazioni di terze parti.