Google ha introdotto le impostazioni di controllo dell'accesso alle app per consentire agli amministratori di Google Workspace for Education di controllare più facilmente il modo in cui le app di terze parti accedono ai dati di Google delle loro organizzazioni' quando gli utenti accedono con 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.
Utilizzare 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, l'app richiede ambiti di base come il profilo dell'ambito di accesso e altri ambiti iniziali necessari per il funzionamento dell'app. In un secondo momento, quando l'utente vuole eseguire un'azione che richiede ambiti aggiuntivi, l'app richiede questi ambiti aggiuntivi e l'utente autorizza solo i nuovi ambiti da una schermata di consenso.
Quando crei un componente aggiuntivo di Google Classroom, devi seguire le indicazioni 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 a un utente del dominio di dare il consenso.
Assicurarsi che tutte le app siano verificate con OAuth
Tutte le app che accedono alle API Google devono verificare di rappresentare con precisione la propria identità e il proprio intento, come specificato dalle Norme sui dati utente: servizi API di Google. Se gestisci più app che utilizzano le API di Google, assicurati che ogni app sia stata verificata. Gli amministratori potrebbero visualizzare 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 ed elimina tutti gli ID client OAuth non in uso.
La verifica delle API OAuth è una procedura utilizzata da Google Cloud Platform 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 restrizioni devono essere conformi alle Norme relative ai dati utente: servizi API di Google. Queste norme richiedono alle app di proteggere i dati utente e di utilizzarli solo per gli scopi autorizzati dall'utente. Le app potrebbero anche dover essere sottoposte a una valutazione di sicurezza indipendente per verificare che soddisfino i requisiti di sicurezza di Google Cloud.
Tieni presente che la procedura di verifica delle API OAuth può richiedere diverse settimane. Una volta verificata l'app, puoi richiedere gli ambiti sensibili o con restrizioni di cui hai bisogno.
Per ulteriori dettagli, consulta le domande frequenti sulla verifica delle API OAuth.
Gestire più ID client OAuth
Un progetto Google Cloud potrebbe avere più ID client OAuth, il che potrebbe richiedere a un amministratore di dominio di configurare l'accesso più volte.
Garantire l'accuratezza degli ID client OAuth
Contatta il tuo team di sviluppo per capire quali ID client OAuth vengono utilizzati per l'integrazione con Google OAuth. Utilizza due progetti Google Cloud diversi per i test e la produzione per aiutare gli amministratori a capire quali ID client OAuth configurare. Elimina tutti gli ID client obsoleti o non aggiornati dai progetti di produzione.
Caricamento di un file CSV
Se hai più ID client, ti consigliamo di utilizzare l'opzione di caricamento collettivo di file 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 | Sì | Uno tra applicazione web, Android o iOS. |
| ID | Sì | Per le app web, inserisci l'ID client OAuth rilasciato all'applicazione. Per le app per Android e iOS, inserisci l'ID client OAuth, l'ID pacchetto o bundle utilizzato dall'app in Google Play o nell'Apple App Store. |
| Unità organizzativa | Sì | Deve essere compilato dal cliente. Inserisci una barra ("/") per applicare l'impostazione di accesso all'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 | Sì | Uno tra attendibile, bloccato o limitato. |
Errori OAuth
Con questi nuovi controlli amministrativi 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 l'applicazione.
Utenti identificati come minori di 18 anni
Gli amministratori possono gestire l'accesso ad 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. In questo modo, l'amministratore può esaminare l'applicazione di terze parti. Gli amministratori possono decidere se consentire o bloccare le applicazioni di terze parti.