Lorsque vous développez et déployez des applications qui utilisent Google OAuth 2.0, il est important de comprendre les différents états dans lesquels une application peut se trouver et comment ces états interagissent avec les commandes de l'administrateur Google Workspace. Cette page fournit une présentation générale des états de publication des applications OAuth , des types d'utilisateurs et des exigences de validation.
Identifier le type d'application
Pour comprendre les règles et les commandes qui s'appliquent à votre projet, déterminez d'abord votre audience cible :
- Applications utilisables partout : ces applications ciblent la plus large audience possible, y compris les titulaires de comptes Google individuels et les utilisateurs d'organisations Google Workspace externes. Elles sont configurées en tant que types d'utilisateurs externes dans la console Google Cloud. Pour en savoir plus, consultez Type d'utilisateur : externe.
- Applications utilisables uniquement au sein d'une organisation Google Workspace : ces applications sont privées et réservées aux utilisateurs de votre propre domaine Google Workspace. Elles ne sont pas accessibles aux utilisateurs externes à votre organisation. Elles sont configurées en tant que types d'utilisateurs internes. Votre application et ses utilisateurs sont soumis aux règles administratives au niveau de l'organisation, qui peuvent remplacer le comportement OAuth standard. Pour en savoir plus, consultez Type d'utilisateur : interne.
Comparaison du comportement de la plate-forme Google OAuth
Le tableau suivant décrit comment les différentes configurations de l'état de publication, du type d'utilisateur et de l'état de validation affectent le comportement et l'accès à l'application. Ces comportements sont régis par les règles de validation OAuth et les règles d'expiration des jetons.
| État de publication | Type d'utilisateur | Utilisateurs tests applicables ? | État de validation | Remarques |
|---|---|---|---|---|
| N/A | Interne | Non | N/A | Tous les utilisateurs de votre organisation peuvent y accéder. La validation n'est pas requise. L'écran de consentement peut ne pas lister les niveaux d'accès. Utile pour les applications à usage interne uniquement. |
| Tests | Externe | Oui | N/A | Seuls les utilisateurs explicitement ajoutés à la liste d'autorisation des utilisateurs tests peuvent accéder à l'application (limite stricte de 100 utilisateurs tests). Exception : si l'application ne demande que des niveaux d'accès d'identité de base (openid, email, profile), tout utilisateur peut y accéder sans figurer sur la liste d'autorisation. Les utilisateurs voient une interface utilisateur d'avertissement indiquant que l'application est en phase de test, plutôt que l'écran standard d'application non validée. Remarque : Les utilisateurs de l'organisation ne sont pas exemptés de ces exigences de test, sauf si le type d'utilisateur de l'application est défini sur Interne. Utile pour le développement et les tests. |
| Publié | Externe | Non | Non validé | Tous les utilisateurs Google y ont accès. Fortement déconseillé. Étant donné que l'application n'a pas terminé la validation de la marque, son nom et son logo ne s'affichent pas sur l'écran de consentement. De plus, pour les applications demandant des niveaux d'accès sensibles ou restreints, des avertissements pour application non validée (interface utilisateur de danger) s'affichent pour les utilisateurs, et une limite stricte de 100 utilisateurs au total s'applique. |
| Publié | Externe | Non | Validé | Tous les utilisateurs Google y ont accès. Obligatoire pour les applications publiques qui demandent des niveaux d'accès sensibles et restreints. Le nom, le logo et les niveaux d'accès de l'application s'affichent sur l'écran de consentement sans avertissement (une fois la marque et les niveaux d'accès validés). |
Remplacements administratifs dans les environnements Google Workspace
Les administrateurs Google Workspace disposent d'un contrôle important sur la façon dont les applications OAuth accèdent aux données de leur organisation, quels que soient les paramètres de l'application dans la console Google Cloud. Ces commandes sont gérées dans la console d'administration Google Workspace sous Commandes des API.
- Contrôle universel : les administrateurs Google Workspace peuvent toujours bloquer n'importe quelle application OAuth, qu'elle soit interne ou externe, en phase de test ou publiée, validée ou non validée, empêchant ainsi leurs utilisateurs de l'autoriser.
- Applications internes : elles sont souvent implicitement approuvées au sein de l'organisation Google Workspace , en particulier si l'administrateur active l'option "Approuver les applications internes appartenant au domaine". Toutefois, les administrateurs peuvent toujours appliquer des libellés tels qu'"Approuvée", "Limitée" ou "Bloquée" pour affiner l'accès. La délégation au niveau du domaine (DWD) peut également être configurée pour contourner le consentement utilisateur pour des niveaux d'accès spécifiques.
- Applications externes
- Non validées : les administrateurs sont peu susceptibles de leur faire confiance et elles peuvent être bloquées ou limitées. Bien qu'un administrateur puisse marquer une application externe non validée comme "Approuvée" pour son domaine, cela est généralement déconseillé.
- Validées : la validation Google renforce la confiance, mais les administrateurs Google Workspace conservent le contrôle total. L'état "Validé" ne remplace pas les paramètres de l'administrateur Google Workspace. Les administrateurs peuvent marquer l'application comme Approuvée (en contournant certaines restrictions de niveau d'accès définies par l'administrateur), Limitée (sous réserve de restrictions de service) ou Bloquée.
Remplacement de l'état "Approuvée" : lorsqu'un administrateur Google Workspace marque une application comme Approuvée, elle est traitée comme une application interne pour cette organisation. Cet état remplace certaines limites OAuth standards pour les utilisateurs de l'organisation, telles que la limite de 100 utilisateurs tests et la limite d'expiration du jeton d'actualisation de sept jours pour les applications dont l'état est Tests.
En substance, le processus de validation de Google est un signal de conformité générale aux règles, mais l' administrateur Google Workspace a l'autorité finale pour déterminer si une application peut accéder aux données de son organisation.
Étapes suivantes
Pour obtenir des informations plus détaillées sur la préparation de votre application pour la production et la gestion des considérations spécifiques à Google Workspace, consultez les ressources suivantes :