Google a lancé des paramètres de contrôle de l'accès des applications pour permettre aux administrateurs Google Workspace for Education de contrôler l'accès des applications tierces aux données Google de leur organisation lorsque les utilisateurs se connectent avec leur compte Google Workspace for Education. Bien qu'aucune action ne soit requise de la part des développeurs d'applications tierces, vous trouverez ci-dessous quelques bonnes pratiques que d'autres développeurs ont trouvées utiles.
Utiliser OAuth incrémentiel
Vous pouvez utiliser l'autorisation incrémentielle pour demander initialement uniquement les niveaux d'accès requis pour démarrer votre application, puis demander des champs d'application supplémentaires lorsque de nouvelles autorisations sont requises. Le contexte de l'application identifie ensuite le motif de la requête à l'utilisateur.
Lors de la connexion, votre application demande des portées de base telles que le profil de portée de connexion et d'autres portées initiales dont elle a besoin pour fonctionner. Plus tard, lorsque l'utilisateur souhaite effectuer une action nécessitant des portées supplémentaires, votre application les demande et l'utilisateur n'autorise que les nouvelles portées à partir d'un écran d'autorisation.
Lorsque vous créez un module complémentaire Google Classroom, vous devez suivre les consignes de Google Workspace Marketplace pour fournir une liste complète des habilitations OAuth requises par votre application. Cela permet à un administrateur de comprendre les portées auxquelles un utilisateur de domaine est invité à donner son consentement.
Vérifier que toutes les applications sont validées par OAuth
Toutes les applications qui accèdent aux API Google doivent vérifier qu'elles représentent précisément leur identité et leur intention, comme spécifié dans le règlement sur les données utilisateur des services d'API Google. Si vous gérez plusieurs applications qui utilisent des API Google, assurez-vous que chacune d'elles a été validée. Les administrateurs peuvent voir tous les ID client OAuth associés à votre marque validée. Pour aider les administrateurs à éviter de configurer des ID client OAuth incorrects, utilisez des projets Google Cloud distincts pour les tests et la production, et supprimez tous les ID client OAuth qui ne sont pas utilisés.
La validation de l'API OAuth est un processus utilisé par Google Cloud Platform pour s'assurer que les applications qui demandent des portées sensibles ou restreintes sont sécurisées et conformes. Le processus de validation permet de protéger les utilisateurs et les données Google Cloud contre les accès non autorisés.
Les applications qui demandent des champs d'application sensibles ou restreints doivent respecter le règlement sur les données utilisateur dans les services d'API Google. Ce règlement exige que les applications protègent les données utilisateur et n'utilisent ces données que pour les finalités autorisées par l'utilisateur. Les applications peuvent également devoir faire l'objet d'une évaluation de sécurité indépendante pour vérifier qu'elles respectent les exigences de sécurité de Google Cloud.
Notez que la procédure de validation de l'API OAuth peut prendre jusqu'à plusieurs semaines. Une fois votre application validée, vous pouvez demander les niveaux d'accès sensibles ou restreints dont vous avez besoin.
Pour en savoir plus, consultez les questions fréquentes sur la validation de l'API OAuth.
Gérer plusieurs ID client OAuth
Un projet Google Cloud peut avoir plusieurs ID client OAuth, ce qui peut nécessiter qu'un administrateur de domaine configure plusieurs fois votre accès.
Assurer l'exactitude des ID client OAuth
Consultez votre équipe de développement pour savoir quels ID client OAuth sont utilisés pour l'intégration avec Google OAuth. Utilisez deux projets Google Cloud différents pour les tests et la production afin d'aider les administrateurs à identifier les ID client OAuth à configurer. Supprimez les ID client obsolètes ou obsolètes de vos projets de production.
Importation au format CSV
Si vous avez plusieurs ID client, nous vous recommandons d'utiliser l'option d'importation groupée au format CSV pour aider les administrateurs à configurer rapidement toutes vos applications.
Les champs sont les suivants :
| Champ | Obligatoire | Remarques |
|---|---|---|
| Nom de l'application | Non | Saisissez le nom de l'application. Les modifications apportées au nom de l'application dans le fichier CSV ne sont pas répercutées dans la console d'administration. |
| Type | Oui | Application Web, Android ou iOS |
| ID | Oui | Pour les applications Web, saisissez l'ID client OAuth émis pour l'application. Pour les applications Android et iOS, saisissez l'ID client OAuth ou l'ID de package ou de bundle utilisé par l'application sur Google Play ou l'App Store d'Apple. |
| Unité organisationnelle | Oui | À renseigner par le client. Saisissez une barre oblique ("/") pour appliquer le paramètre d'accès à l'application à l'ensemble du domaine. Pour appliquer des paramètres d'accès à des unités organisationnelles spécifiques, ajoutez une ligne à la feuille de calcul pour chaque unité organisationnelle, en répétant le nom, le type et l'ID de l'application. (par exemple, "/unité_organisationnelle_1/sous-unité_1"). |
| Accès | Oui | trusted (approuvé), blocked (bloqué) ou limited (limité). |
Erreurs OAuth
Deux messages d'erreur ont été introduits avec ces nouvelles commandes d'administration.
- Erreur 400 : access_not_configure : reçue lorsqu'une connexion OAuth est refusée, car votre application n'a pas été configurée.
- Erreur 400 : admin_policy_enforced : reçue lorsqu'une connexion OAuth est refusée, car l'administrateur a bloqué votre application.
Utilisateurs désignés comme ayant moins de 18 ans
Les administrateurs peuvent gérer l'accès aux applications tierces non configurées pour les utilisateurs désignés comme ayant moins de 18 ans. Si un utilisateur rencontre le message d'erreur "Accès bloqué: l'administrateur de votre établissement doit examiner [nom de l'application]", il doit envoyer une demande d'accès depuis le message d'erreur. Cela permet à leur administrateur d'examiner l'application tierce. Ce sont les administrateurs qui choisissent d'autoriser ou de bloquer des applications tierces.