Chez DoiT, notre mission consiste à aider les utilisateurs cloud à gérer leurs workloads de façon efficace, sécurisée et économique. Parmi les défis que rencontrent certains de nos clients figure l'authentification aux API Google Workspace, en particulier lorsqu'un appel API doit exécuter une opération au nom d'un utilisateur sans solliciter son interaction directe — un scénario connu sous le nom de flux OAuth à 2 étapes (2 Legged OAuth flow).
Google propose trois méthodes d'authentification pour interagir avec ses API :
1. Clés API : adaptées à l'accès à des informations publiques, comme l'interrogation de l'API Google Air Quality pour récupérer des données sur la qualité de l'air.
2. Identifiants OAuth : utilisés lorsqu'une application a besoin du consentement de l'utilisateur pour exécuter des appels API en son nom, dans un flux OAuth à 3 étapes.
- Authentification par compte de service : c'est le sujet qui nous intéresse aujourd'hui. Cette méthode permet d'agir au nom des utilisateurs sans aucune interaction de leur part. Elle s'inscrit dans un flux OAuth à 2 étapes.
Prenons un cas d'usage concret : récupérer les événements de l'agenda d'un utilisateur de notre organisation Workspace, dans le cadre d'une application backend qui analyse les emplois du temps pour déterminer le créneau optimal d'un événement.
Les clés API ne conviennent pas ici (elles ne fonctionnent pas avec les API non publiques) ; les identifiants OAuth, eux, sont utilisables, mais imposent le consentement de l'utilisateur. À l'inverse, l'authentification par compte de service permet d'accéder au point de terminaison sans intervention de l'utilisateur — c'est cette méthode que nous allons explorer ici.
Pour mettre en place l'authentification par compte de service et autoriser l'accès à l'API Google Calendar au nom des utilisateurs, suivez ces étapes :
1. Créez un compte de service Google Cloud.
2. Déléguez une autorité à l'échelle du domaine au compte de service — opération réservée aux administrateurs Google Workspace.
3. Authentifiez-vous auprès de l'API Google Calendar avec les identifiants délégués, un procédé également appelé usurpation d'identité utilisateur (user impersonation).
Voici un extrait illustrant comment initialiser le client API avec des identifiants délégués en Python :
from __future__ import print_function
from googleapiclient.discovery import build
from google.oauth2.credentials import Credentials
from google.oauth2 import service_account
SCOPES = ['https://www.googleapis.com/auth/calendar']
SERVICE_ACCOUNT_FILE = 'credentials.json'
credentials = service_account.Credentials.from_service_account_file(
SERVICE_ACCOUNT_FILE, scopes=SCOPES)
def main():
delegated_credentials = credentials.with_subject('[email protected]')
service = build('calendar', 'v3', credentials=delegated_credentials)
events_results = service.calendars().events.list(calendarId='primary').execute()
events = events_result.get("items", [])
if not events:
print("No upcoming events found.")
return
for event in events:
start = event["start"].get("dateTime", event["start"].get("date"))
print(start, event["summary"])
if __name__ == '__main__':
main()
Point important : le client API doit être initialisé avec les identifiants délégués pour chaque utilisateur au nom duquel des appels API seront effectués :
delegated_credentials = credentials.with_subject('[email protected]')
service = build('calendar', 'v3', credentials=delegated_credentials)
[email protected] désigne l'utilisateur Workspace au nom duquel l'appel API sera exécuté, ici pour accéder à son agenda.
Cette approche se distingue de la méthode des identifiants OAuth présentée dans le guide de démarrage rapide du client Python pour l'API Calendar, lequel s'appuie sur un flux OAuth à 3 étapes nécessitant le consentement de l'utilisateur.
Notre objectif est de clarifier l'authentification backend aux API Google Workspace, en particulier lorsque l'interaction utilisateur n'a pas sa place dans le flux d'authentification. Nous espérons que ce guide lèvera vos doutes. Pour en savoir plus sur nos domaines d'expertise, rendez-vous sur https://www.doit.com/services/
employed
Should be "deployed" I think :)
Répondre
retrieving
"r" should be upper case.
Répondre
C'est le sujet qui nous intéresse aujourd'hui : cette méthode permet d'agir au nom des utilisateurs sans aucune interaction de leur part. Elle s'inscrit dans un flux OAuth à 2 étapes.
Formatting should not be bold letters.
Répondre
Voir toutes les réponses
par
[Moderniser l'accès aux applications internes GKE : du VPN à la passerelle externe activée par IAP\ \
13 janv. 2025
par
[Concevoir une architecture AWS avec des serveurs MCP et des Strands Agents\ \
22 sept. 2025
par
[Empreintes JA3 et JA4 dans AWS WAF et au-delà\ \
10 avr. 2025
par
[Modèles d'architecture VPC : approches autonomes et centralisées dans AWS et GCP\ \
25 nov. 2024
par
[Stanford vient d'enterrer le prompt engineering en 8 mots (et j'ai du mal à croire que ça ait marché)\ \
19 oct. 2025
[A clap icon25K\ \
[10 compétences incontournables pour Claude (et tout agent de code) en 2026\ \
9 mars
[A clap icon1K\ \
[La fin des dashboards et des design systems\ \
26 nov. 2025
[A clap icon6.5K\ \
[Anthropic ajoute le (nouveau) mode automatique de Claude Code (fini les modes de permission)\ \
il y a 6 j.
[A clap icon391\ \
par
[Vous achetez sans doute la mauvaise machine pour l'IA locale — la vérité Mac Mini M4 vs Mini PC que personne…\ \
20 mars
[A clap icon1.1K\ \
par
[J'ai arrêté ChatGPT pendant 30 jours. Ce qui est arrivé à mon cerveau était terrifiant.\