Google a introduit des paramètres de contrôle d'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 jugées utiles.
Utiliser le protocole 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 adressée à l'utilisateur.
Lors de la connexion, votre application demande les niveaux d'accès de base, tels que le profil du champ d'application de connexion, ainsi que d'autres champs d'application initiaux dont elle a besoin pour fonctionner. Par la suite, lorsque l'utilisateur souhaite effectuer une action qui nécessite des champs d'application supplémentaires, votre application demande ces champs d'application supplémentaires et l'utilisateur n'autorise que les nouveaux à partir d'un écran de consentement.
Lorsque vous créez un module complémentaire Google Classroom, vous devez suivre les conseils de Google Workspace Marketplace pour fournir la liste complète des champs d'application OAuth requis par votre application. Cette étape est nécessaire pour qu'un administrateur sache pour quels niveaux d'accès un utilisateur de domaine est invité à donner son consentement.
Assurez-vous 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 avec précision leur identité et leur intention, conformément au règlement sur les données utilisateur des services d'API de Google. Si vous gérez plusieurs applications qui utilisent des API Google, assurez-vous que chacune 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 niveaux d'accès sensibles ou restreints 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 niveaux d'accès sensibles ou restreints doivent respecter le règlement sur les données utilisateur dans les services d'API Google. Cette règle impose aux applications de protéger les données utilisateur et de n'utiliser ces données qu'aux fins autorisées par l'utilisateur. Les applications peuvent également être soumises à une évaluation de sécurité indépendante afin de vérifier qu'elles répondent aux exigences de sécurité de Google Cloud.
Notez que le processus de validation de l'API OAuth peut prendre 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.
Garantir l'exactitude des ID client OAuth
Renseignez-vous auprès de votre équipe de développement pour savoir quels ID client OAuth sont utilisés pour l'intégration à Google OAuth. Utilisez deux projets Google Cloud différents pour les tests et la production afin d'aider les administrateurs à comprendre quels ID client OAuth doivent être configurés. Supprimez tous 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 que vous apportez au nom de l'application dans le fichier CSV ne sont pas mises à jour 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 de l'application à l'ensemble de votre 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é_org_1/sous_unité_1'). |
| Accès | Oui | Approuvée, Bloquée ou Limitée |
Erreurs OAuth
Deux messages d'erreur ont été introduits dans ces nouvelles commandes d'administrateur.
- 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 demander l'accès depuis le message d'erreur. Cela permet à leur administrateur d'examiner l'application tierce. Les administrateurs peuvent décider d'autoriser ou de bloquer les applications tierces.