Here at DoiT, our mission revolves around assisting cloud users in managing their workloads efficiently, securely, and in a cost-optimized manner. Among the challenges that some of our customers encounter is the authentication process for Google Workspace APIs, particularly when the API call is meant to execute an operation on behalf of a user without requiring their direct interaction, a scenario known as the 2 Legged OAuth flow.
Google offers three authentication methods for interacting with their APIs:
1. API Keys: Suitable for accessing publicly available information, such as querying the Google Air Quality API for air quality data.
2. OAuth Credentials: Used when an application necessitates user consent to execute API calls on their behalf in a 3-legged OAuth flow.
- Service Account Authentication: The focus of our discussion today, this method enables actions to be performed on behalf of users without requiring their interaction. It operates within a 2-legged OAuth flow.
Let’s consider a practical use case: Retrieving calendar events for a user within our Workspace organization as part of a backend application that analyzes users’ schedules to determine optimal event timing.
While API keys are inadequate for this task (cannot be used for non-public APIs), OAuth credentials can be employed, albeit requiring user consent. In contrast, service account authentication allows access to the API endpoint without user involvement, a method we’ll explore here.
To implement service account authentication and authorize with the Google Calendar API on behalf of users, follow these steps:
1. Create a Google Cloud service account.
2. Delegate domain-wide authority to the service account, a task reserved for Google Workspace admins.
3. Authenticate with the Google Calendar API using the delegated credentials, a process also known as user impersonation.
Here’s a snippet illustrating how to initialize the API client with delegated credentials in 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()
It’s crucial to note that the API client must be initialized with the delegated credentials for each user on whose behalf API calls will be made:
delegated_credentials = credentials.with_subject('[email protected]')
service = build('calendar', 'v3', credentials=delegated_credentials)
[email protected] is the Workspace user that the API call will be executed on his behalf, to access their calendar in that case.
This approach differs from the OAuth credentials method, as demonstrated in the Calendar Python API client’s quickstart guide, which utilizes a 3-legged OAuth flow requiring user consent.
Our aim is to provide clarity on backend authentication with Google Workspace APIs, particularly in scenarios where user interaction shouldn’t be part of the authentication flow. We hope this guide helps alleviate any uncertainty. We invite you to read more about our areas of expertise on https://www.doit.com/services/
employed
Should be "deployed" I think :)
Reply
retrieving
"r" should be upper case.
Reply
The focus of our discussion today, this method enables actions to be performed on behalf of users without requiring their interaction. It operates within a 2-legged OAuth flow.
Formatting should not be bold letters.
Reply
See all responses
by
[Modernizing GKE Internal Applications Access: From VPN to IAP-Enabled External Gateway\ \
Jan 13, 2025
by
[Building AWS Architecture with MCP Servers and Strands Agents\ \
Sep 22, 2025
by
[JA3 and JA4 Fingerprints in AWS WAF and Beyond\ \
Apr 10, 2025
by
[VPC Architecture Patterns: Standalone vs. Centralized Approaches in AWS and GCP\ \
Nov 25, 2024
by
[Stanford Just Killed Prompt Engineering With 8 Words (And I Can’t Believe It Worked)\ \
Oct 19, 2025
[A clap icon25K\ \
[10 Must-Have Skills for Claude (and Any Coding Agent) in 2026\ \
Mar 9
[A clap icon1K\ \
[The End of Dashboards and Design Systems\ \
Nov 26, 2025
[A clap icon6.5K\ \
[Anthropic Adds (New) Claude Code Auto Mode (No More Permission Modes)\ \
6d ago
[A clap icon391\ \
by
[You Are Probably Buying the Wrong Machine for Local AI — The Mac Mini M4 vs Mini PC Truth Nobody…\ \
Mar 20
[A clap icon1.1K\ \
by
[I Stopped Using ChatGPT for 30 Days. What Happened to My Brain Was Terrifying.\