Dans l’API Google Drive, OAuth permet à un site d’agir au nom d’une personne : quelqu’un se connecte avec Google, approuve l’accès, et le site emprunte l’autorisation de cette personne. Un compte de service est une identité Google distincte qui appartient au site et ne voit que les dossiers que vous partagez avec elle. Les connexions OAuth établies avec votre propre app Google peuvent expirer au bout de 7 jours ou exiger une validation de Google ; un compte de service évite les deux, mais vous confie un fichier de clé à protéger.
Deux façons pour un site d’accéder à Google Drive
Un plugin WordPress qui affiche des fichiers Drive doit prouver à Google qu’il a le droit de les lire. Google propose deux grandes façons de le faire, et la différence se comprend mieux avec une comparaison de tous les jours.
OAuth : prêter votre propre accès
Imaginez un client d’hôtel qui signe un formulaire pour que le concierge récupère ses colis à sa place. Avec OAuth, vous cliquez sur Se connecter avec Google, Google affiche un écran qui indique quelle app demande l’accès et ce qu’elle veut voir, et vous cliquez sur Autoriser. Google remet alors au site un laissez-passer durable (appelé jeton d’actualisation, ou refresh token) pour qu’il puisse revenir sans vous redemander. Le site voit ce que voit votre compte, dans les limites de ce qu’il a demandé.
Compte de service : un nouveau collègue avec son propre badge
Imaginez maintenant que vous embauchez un assistant avec son propre badge. Au départ, il n’a accès à rien. Vous partagez un dossier avec lui, comme vous le feriez avec un collègue, et c’est tout ce qu’il peut ouvrir. Un compte de service fonctionne ainsi : c’est une identité Google pour un logiciel, avec sa propre adresse e-mail (qui se termine par iam.gserviceaccount.com). Le guide de Google indique d’ailleurs que vous pouvez traiter l’adresse e-mail du compte de service comme un compte utilisateur dans les paramètres de partage. Personne ne se connecte et il n’y a aucun écran d’approbation.
Pourquoi les connexions Google Drive des sites expirent
Si vous avez déjà vu un plugin Drive vous demander de vous « reconnecter » chaque semaine, ou afficher une erreur comme invalid_grant, la cause est en général le laissez-passer OAuth, pas le plugin.
Beaucoup de plugins vous demandent de créer votre propre app Google : un projet Google Cloud avec un écran de consentement, un ID client, une adresse de redirection et une liste d’utilisateurs de test. Une nouvelle app démarre avec l’état de publication Test. La documentation de Google est claire : une app dans cet état reçoit un jeton d’actualisation expirant dans sept jours, sauf si elle ne demande que des informations de profil de base. Lire Drive ne fait pas partie des informations de profil de base : le laissez-passer cesse donc de fonctionner une semaine après la connexion.
Sortir l’app de l’état Test (le bouton Publish app, publier l’application, sur la page Audience de la console Google) supprime la limite de 7 jours, mais amène le sujet suivant : la validation. Et même pour une app publiée, le laissez-passer peut s’arrêter pour d’autres raisons que Google énumère :
- la personne révoque l’accès de l’app dans son compte Google ;
- le laissez-passer n’a pas été utilisé depuis six mois ;
- le compte a atteint la limite de Google en nombre de laissez-passer actifs ;
- un administrateur Google Workspace restreint l’app pour l’organisation.
Il y a aussi un facteur humain. Une connexion OAuth est liée au compte d’une personne. Si le collègue qui a cliqué sur Autoriser quitte l’entreprise et que son compte est fermé, le site perd l’accès en même temps.
Pourquoi Google demande une validation
Quand une app demande un accès, elle précise un ou plusieurs champs d’application (les « scopes ») : l’étendue de l’accès qu’elle souhaite. Google classe les champs d’application en non sensibles, sensibles et restreints. Pour Drive, ceux qui permettent de lire tout le contenu du Drive d’une personne, y compris celui en lecture seule, sont classés comme restreints.
Une app publiée qui utilise des champs d’application restreints et s’adresse au public doit passer la validation des champs d’application restreints de Google. Si les données transitent par un serveur, comme c’est le cas avec un site web, Google exige aussi une évaluation de sécurité par un évaluateur indépendant, à renouveler au moins tous les 12 mois. Google prévient que la procédure peut prendre plusieurs semaines.
Tant qu’une app n’est pas validée, les personnes qui se connectent voient un avertissement indiquant que Google ne l’a pas validée, et l’app est limitée à 100 utilisateurs. Google autorise une app non validée pour un usage personnel par moins de 100 personnes : le propriétaire d’un site peut donc passer l’avertissement pour sa propre app. Cela fonctionne, mais ce n’est pas quelque chose à confier à un client.
C’est pourquoi les plugins Drive suivent en général l’une de ces trois voies :
- L’app validée de l’éditeur du plugin. Vous cliquez sur Se connecter avec Google et approuvez l’app de l’éditeur. Aucun travail dans Google Cloud pour vous, mais vous donnez à cette app l’accès à votre Drive par votre propre compte.
- Votre propre app OAuth. Vous créez l’app vous-même dans Google Cloud. Laissée en Test, elle expire chaque semaine ; publiée, elle affiche l’avertissement d’app non validée.
- Un compte de service. Ni connexion ni écran de consentement : rien de ce qui précède ne s’applique.
Il existe aussi un champ d’application restreint à certains fichiers, souvent appelé « drive.file », que Google classe comme non sensible. Il ne couvre que les fichiers précis qu’une personne ouvre ou crée avec l’app : il convient donc aux outils qui enregistrent ou sélectionnent des fichiers isolés, pas à une page qui doit montrer tout ce que vous ajoutez dans un dossier.
Ce qu’un compte de service change
Avec un compte de service, le site a sa propre identité, et c’est vous qui décidez de ce qu’il voit en partageant. Cela change plusieurs choses à la fois.
- Pas d’expiration hebdomadaire. La connexion utilise un fichier de clé, pas une connexion de personne. Google l’écrit : par défaut, les clés de compte de service n’expirent jamais. La clé cesse de fonctionner si vous la supprimez dans Google Cloud, ou si votre organisation a fixé une durée de vie maximale des clés.
- Ni écran de consentement, ni utilisateurs de test, ni app à publier. Personne n’approuve rien : Google n’a donc aucun avertissement à afficher.
- Un accès visible. Le compte de service ne voit que les dossiers partagés avec lui. Ouvrez la fenêtre de partage du dossier dans Drive : son adresse y figure comme celle de n’importe quelle personne. Retirez-la et l’accès s’arrête aussitôt.
- Pas lié à une personne. Les salariés vont et viennent ; le site garde sa propre identité.
Il y a tout de même des contreparties. Le fichier de clé est un mot de passe : quiconque le possède peut lire ce que le compte de service peut lire, il ne faut donc jamais l’envoyer par e-mail ni le laisser dans un dossier public. La mise en place demande une dizaine de minutes dans la console Google Cloud. Et dans Google Workspace, deux réglages d’organisation peuvent gêner : les organisations Google Cloud créées depuis le 3 mai 2024 bloquent par défaut la création de clés, et certaines organisations interdisent le partage avec des adresses extérieures au domaine. Dans les deux cas, un administrateur peut faire une exception.
Les drives partagés fonctionnent aussi. Vous ajoutez l’adresse du compte de service comme membre du drive partagé, ou vous partagez avec elle un seul dossier de ce drive.
Compte de service vs OAuth pour Google Drive : côte à côte
| App validée de l’éditeur du plugin | Votre propre app OAuth | Compte de service | |
|---|---|---|---|
| Qui se connecte | Vous, avec votre compte Google | Vous, avec votre compte Google | Personne |
| Peut s’arrêter tout seul | Révocation, 6 mois sans utilisation, règle d’administration | Après 7 jours en Test, plus les mêmes raisons | Non, seulement si la clé est supprimée ou le dossier n’est plus partagé |
| Écran d’avertissement Google | Non | Oui, tant que Google ne l’a pas validée | Aucun écran |
| Ce qu’elle peut voir | Ce que l’app a demandé dans votre Drive | Ce que l’app a demandé dans votre Drive | Seulement les dossiers partagés avec lui |
| Votre travail de mise en place | Un clic | Écran de consentement, ID client, adresse de redirection, utilisateurs de test | Un projet, un fichier de clé, un partage |
| Idéal pour | Les connexions rapides quand vous faites confiance à l’éditeur | Les développeurs qui testent leurs propres outils | Les sites qui montrent vos fichiers à vos utilisateurs |
Lequel votre site devrait-il utiliser
OAuth est le bon outil quand chaque visiteur doit accéder à son propre Drive : par exemple un formulaire où l’on choisit un fichier dans son compte Google. Seule la personne peut donner cette autorisation, et un compte de service ne peut pas la remplacer.
Un compte de service convient mieux quand le site montre vos fichiers à vos utilisateurs : un espace client, un espace revendeurs, une page de documents pour les salariés. Le site a alors besoin d’une connexion stable à quelques dossiers, et c’est la connexion à votre site, pas Google, qui décide de qui voit quoi.
C’est le choix que nous avons fait pour Google Drive Portal. Il se connecte uniquement avec un compte de service : aucune adresse de redirection à copier, aucun écran de consentement, aucun utilisateur de test, aucune app à publier ni à faire valider. Le guide de connexion détaille le projet, la clé et le partage, et la page Corriger les problèmes de connexion explique chaque message en termes simples. Pour voir où cela s’inscrit dans une vraie mise en place, lisez comment créer un espace client Google Drive.
En résumé
OAuth emprunte l’accès d’une personne. Avec votre propre app Google, il expire tous les 7 jours tant que l’app est en Test, et une fois publiée elle affiche un avertissement jusqu’à ce que Google la valide, une procédure qui, pour un accès complet à Drive, comprend une évaluation de sécurité annuelle. L’app validée d’un éditeur de plugin évite cela, mais la connexion appartient toujours au compte d’une personne.
Un compte de service donne au site sa propre identité, qui ne voit que ce que vous partagez, n’expire pas par défaut et n’a besoin d’aucun écran de validation. En échange, vous avez un fichier de clé à protéger et une courte mise en place dans Google Cloud. Pour un site qui montre vos dossiers Drive à vos clients ou à vos salariés, c’est en général le choix le plus serein. Si vous voulez seulement afficher un dossier public, vous n’avez peut-être besoin ni de l’un ni de l’autre : voyez comment intégrer un dossier Google Drive dans WordPress.
Questions fréquentes
Pourquoi mon plugin Google Drive se déconnecte-t-il tous les 7 jours ?
Le plugin utilise très probablement une app Google que vous avez créée et qui est encore à l’état de publication Test. Google fait expirer au bout de 7 jours les jetons d’actualisation des apps en Test : vous devez donc vous reconnecter chaque semaine.
Une clé de compte de service expire-t-elle ?
Pas par défaut. Elle fonctionne tant que vous ne la supprimez pas dans Google Cloud, sauf si votre organisation a fixé une durée de vie maximale des clés.
Un compte de service a-t-il besoin de la validation d’app de Google ?
La validation d’app de Google concerne l’écran où les personnes se connectent et approuvent une app. Un compte de service n’a ni connexion ni écran d’approbation : vous lui donnez accès en partageant des dossiers avec son adresse.
Un compte de service peut-il voir tout mon Google Drive ?
Non. Au départ il n’a accès à rien, et il ne voit que les fichiers, dossiers et drives partagés que vous partagez avec son adresse e-mail. Retirez le partage d’un dossier et il perd l’accès.
