Bei DoiT haben wir uns zur Aufgabe gemacht, Cloud-Nutzer dabei zu unterstützen, ihre workloads effizient, sicher und kostenoptimiert zu betreiben. Eine Hürde, der einige unserer Kunden immer wieder begegnen, ist die Authentifizierung gegenüber Google Workspace APIs – vor allem dann, wenn ein API-Aufruf im Namen eines Nutzers erfolgen soll, ohne dass dieser aktiv zustimmen muss. Dieses Szenario kennt man als 2-Legged OAuth Flow.
Google bietet drei Authentifizierungsmethoden für die Arbeit mit seinen APIs:
1. API Keys: Geeignet für den Zugriff auf öffentlich verfügbare Informationen, etwa für Abfragen der Google Air Quality API.
2. OAuth Credentials: Kommen zum Einsatz, wenn eine Anwendung die Zustimmung des Nutzers braucht, um in dessen Namen API-Aufrufe in einem 3-Legged OAuth Flow auszuführen.
- Service Account Authentication: Der Schwerpunkt unseres heutigen Beitrags. Mit dieser Methode lassen sich Aktionen im Namen von Nutzern ausführen, ohne dass diese eingreifen müssen. Sie läuft im 2-Legged OAuth Flow.
Schauen wir uns einen praktischen Anwendungsfall an: Das Abrufen von Kalendereinträgen eines Nutzers innerhalb unserer Workspace-Organisation – im Rahmen einer Backend-Anwendung, die die Terminkalender der Nutzer auswertet, um optimale Zeitfenster für Termine zu finden.
API Keys reichen dafür nicht aus (sie funktionieren nicht mit nicht-öffentlichen APIs). OAuth Credentials wären zwar nutzbar, setzen aber die Zustimmung des Nutzers voraus. Die Service Account Authentication dagegen erlaubt den Zugriff auf den API-Endpunkt ganz ohne Beteiligung des Nutzers – und genau diese Methode sehen wir uns hier näher an.
Um Service Account Authentication zu implementieren und sich bei der Google Calendar API im Namen von Nutzern zu autorisieren, gehen Sie wie folgt vor:
1. Erstellen Sie einen Google Cloud Service Account.
2. Übertragen Sie dem Service Account domainweite Berechtigungen (Domain-Wide Authority) – das ist ausschließlich Google Workspace-Admins vorbehalten.
3. Authentifizieren Sie sich bei der Google Calendar API mit den delegierten Credentials – ein Verfahren, das auch als User Impersonation bekannt ist.
Hier ein Code-Snippet, das zeigt, wie der API-Client mit delegierten Credentials in Python initialisiert wird:
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()
Wichtig: Der API-Client muss für jeden Nutzer, in dessen Namen API-Aufrufe erfolgen sollen, mit den passenden delegierten Credentials initialisiert werden:
delegated_credentials = credentials.with_subject('[email protected]')
service = build('calendar', 'v3', credentials=delegated_credentials)
[email protected] ist in diesem Fall der Workspace-Nutzer, in dessen Namen der API-Aufruf erfolgt – um auf dessen Kalender zuzugreifen.
Dieser Ansatz unterscheidet sich von der OAuth-Credentials-Methode, wie sie im Quickstart-Guide des Calendar Python API Clients beschrieben wird. Dort kommt ein 3-Legged OAuth Flow zum Einsatz, der die Zustimmung des Nutzers verlangt.
Unser Ziel ist es, Klarheit rund um die Backend-Authentifizierung mit Google Workspace APIs zu schaffen – gerade in Szenarien, in denen Nutzerinteraktion im Authentifizierungsablauf nichts zu suchen hat. Wir hoffen, dieser Leitfaden räumt offene Fragen aus dem Weg. Mehr zu unseren Kompetenzfeldern finden Sie unter https://www.doit.com/services/
employed
Should be "deployed" I think :)
Antworten
retrieving
"r" should be upper case.
Antworten
Der Schwerpunkt unseres heutigen Beitrags. Mit dieser Methode lassen sich Aktionen im Namen von Nutzern ausführen, ohne dass diese eingreifen müssen. Sie läuft im 2-Legged OAuth Flow.
Formatting should not be bold letters.
Antworten
Alle Antworten anzeigen
von
[Modernizing GKE Internal Applications Access: From VPN to IAP-Enabled External Gateway\ \
13. Januar 2025
von
[Building AWS Architecture with MCP Servers and Strands Agents\ \
22. September 2025
von
[JA3 and JA4 Fingerprints in AWS WAF and Beyond\ \
10. April 2025
von
[VPC Architecture Patterns: Standalone vs. Centralized Approaches in AWS and GCP\ \
25. November 2024
von
[Stanford Just Killed Prompt Engineering With 8 Words (And I Can't Believe It Worked)\ \
19. Oktober 2025
[A clap icon25K\ \
[10 Must-Have Skills for Claude (and Any Coding Agent) in 2026\ \
9. März
[A clap icon1K\ \
[The End of Dashboards and Design Systems\ \
26. November 2025
[A clap icon6.5K\ \
[Anthropic Adds (New) Claude Code Auto Mode (No More Permission Modes)\ \
vor 6 Tagen
[A clap icon391\ \
von
[You Are Probably Buying the Wrong Machine for Local AI — The Mac Mini M4 vs Mini PC Truth Nobody…\ \
20. März
[A clap icon1.1K\ \
von
[I Stopped Using ChatGPT for 30 Days. What Happened to My Brain Was Terrifying.\