Google a introduit des paramètres de contrôle de l'accès des applications pour permettre aux administrateurs Google Workspace for Education de contrôler plus facilement 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. Aucune action n'est requise de la part des développeurs d'applications tierces, mais voici quelques bonnes pratiques que d'autres développeurs ont trouvées utiles.
Utiliser OAuth incrémental
Vous pouvez utiliser l'autorisation incrémentale pour demander initialement uniquement les champs d'application nécessaires au démarrage de votre application, puis demander des champs d'application supplémentaires lorsque de nouvelles autorisations sont requises. Le contexte de l'application identifie ensuite la raison de la demande auprès de l'utilisateur.
Lors de la connexion, votre application demande des champs d'application de base tels que le profil de champ d'application de connexion et d'autres champs d'application initiaux dont votre application a besoin pour fonctionner. Plus tard, 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 champs d'application à 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 et fournir une liste complète des champs d'application OAuth dont votre application a besoin. Cela est nécessaire pour qu'un administrateur comprenne les champs d'application pour lesquels un utilisateur du domaine est invité à donner son consentement.
S'assurer que toutes les applications sont validées par OAuth
Toutes les applications qui accèdent aux Google APIs doivent vérifier qu'elles représentent avec précision leur identité et leur intention, comme spécifié dans le Règlement sur les données utilisateur des Services d'API de Google. Si vous gérez plusieurs applications qui utilisent les 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 que Google Cloud Platform utilise pour s'assurer que les applications qui demandent des champs d'application 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 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 qu'elles n'utilisent les données qu'aux fins que l'utilisateur a autorisées. Les applications peuvent également avoir besoin de faire l'objet d'une évaluation de sécurité indépendante pour 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 champs d'application 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 comporter plusieurs ID client OAuth, ce qui peut nécessiter qu'un administrateur de domaine configure votre accès plusieurs fois.
S'assurer de l'exactitude des ID client OAuth
Vérifiez 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 configurer. Supprimez tous les ID client obsolètes de vos projets de production.
Importation au format CSV
Si vous disposez de 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 | Spécifiez l'un des contrôles suivants : 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é d'organisation | Oui | À remplir par le client. Saisissez une barre oblique (/) pour appliquer le paramètre d'accès à 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 de l'application, le type et l'ID. (par exemple, "/org_unit_1/sub_unit_1"). |
| Accès | Oui | Spécifiez l'un des contrôles suivants : approuvé, bloqué ou limité. |
Erreurs OAuth
Deux messages d'erreur ont été introduits avec ces nouvelles commandes d'administrateur.
- Erreur 400 : access_not_configured : s'affiche lorsqu'une connexion OAuth est refusée, car votre application n'a pas été configurée.
- Erreur 400 : admin_policy_enforced : s'affiche 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 reçoit 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. L'administrateur peut ainsi examiner l'application tierce. Les administrateurs peuvent décider d'autoriser ou de bloquer les applications tierces.