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. Toutefois, vous trouverez ci-dessous quelques bonnes pratiques qui ont été utiles à d'autres développeurs.
Utiliser OAuth incrémentiel
Vous pouvez utiliser l'autorisation incrémentielle pour demander initialement uniquement les champs d'application requis pour démarrer votre application, puis demander des champs d'application supplémentaires à mesure que de nouvelles autorisations sont requises. Le contexte de l'application identifie ensuite le motif de la demande à l'utilisateur.
Lors de la connexion, votre application demande des autorisations de base telles que l'autorisation de profil de connexion et d'autres autorisations initiales dont elle a besoin pour fonctionner. Plus tard, lorsque l'utilisateur souhaite effectuer une action nécessitant des niveaux d'accès supplémentaires, votre application demande ces niveaux d'accès supplémentaires et l'utilisateur n'autorise que les nouveaux niveaux d'accès à partir d'un écran d'autorisation.
Lorsque vous créez un module complémentaire Google Classroom, vous devez suivre les conseils Google Workspace Marketplace et fournir une liste complète des habilitations OAuth requises par votre application. Cela permet à un administrateur de comprendre les niveaux d'accès pour lesquels le consentement d'un utilisateur du domaine est demandé.
S'assurer 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 fidèlement 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 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 des 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 des applications qu'elles protègent les données utilisateur et qu'elles ne les utilisent qu'aux fins autorisées par l'utilisateur. Il est également possible que les applications doivent 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 la procédure 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 des applications 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.
Vérifier l'exactitude des ID client OAuth
Renseignez-vous auprès de votre équipe de développement pour savoir quels ID clients 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 les ID client obsolètes ou périmés 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 | L'une des options suivantes : 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 | À remplir 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 au tableur pour chaque unité organisationnelle, en répétant le nom, le type et l'ID de l'application. (par exemple, "/org_unit_1/sub_unit_1"). |
| Accès | Oui | Spécifiez l'une des valeurs suivantes : trusted, blocked ou limited. |
Erreurs OAuth
Deux messages d'erreur ont été introduits avec ces nouvelles commandes d'administration.
- 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 indiqué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 l'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. Ainsi, leur administrateur peut examiner l'application tierce. Les administrateurs peuvent choisir d'autoriser ou de bloquer des applications tierces.