In DoiT la nostra missione è aiutare chi usa il cloud a gestire i propri workloads in modo efficiente, sicuro e ottimizzato sui costi. Una delle sfide che alcuni clienti ci portano riguarda l'autenticazione alle API di Google Workspace, soprattutto quando la chiamata API deve eseguire un'operazione per conto di un utente senza richiederne l'interazione diretta: lo scenario noto come flusso 2-Legged OAuth.
Google mette a disposizione tre metodi di autenticazione per interagire con le proprie API:
1. API Keys: indicate per accedere a informazioni pubbliche, ad esempio per interrogare la Google Air Quality API e ottenere i dati sulla qualità dell'aria.
2. OAuth Credentials: si usano quando un'applicazione ha bisogno del consenso dell'utente per eseguire chiamate API per suo conto, in un flusso 3-Legged OAuth.
- Service Account Authentication: il tema centrale di questo articolo. Permette di compiere azioni per conto degli utenti senza alcuna interazione da parte loro e opera in un flusso 2-Legged OAuth.
Prendiamo un caso d'uso concreto: recuperare gli eventi del calendario di un utente della nostra organizzazione Workspace nell'ambito di un'applicazione backend che analizza le agende per individuare l'orario migliore per un evento.
Le API keys non sono adatte allo scopo (non si possono usare con API non pubbliche), mentre le OAuth credentials richiederebbero il consenso dell'utente. La service account authentication, invece, consente di accedere all'endpoint API senza alcun coinvolgimento dell'utente: ed è proprio il metodo che approfondiamo qui.
Per implementare la service account authentication e autorizzare le chiamate alla Google Calendar API per conto degli utenti, i passaggi sono questi:
1. Creare un service account in Google Cloud.
2. Delegare l'autorità domain-wide al service account, operazione riservata agli amministratori di Google Workspace.
3. Autenticarsi alla Google Calendar API tramite le credenziali delegate, processo noto anche come user impersonation.
Ecco uno snippet che mostra come inizializzare il client API con credenziali delegate 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()
Un punto da non sottovalutare: il client API va inizializzato con le credenziali delegate per ogni singolo utente per conto del quale si effettueranno le chiamate API:
delegated_credentials = credentials.with_subject('[email protected]')
service = build('calendar', 'v3', credentials=delegated_credentials)
[email protected] è l'utente Workspace per conto del quale viene eseguita la chiamata API, in questo caso per accedere al suo calendario.
Questo approccio è diverso dal metodo OAuth credentials illustrato nella guida quickstart del client Python della Calendar API, che si basa su un flusso 3-Legged OAuth e richiede il consenso dell'utente.
Il nostro obiettivo è fare chiarezza sull'autenticazione backend con le API di Google Workspace, in particolare negli scenari in cui l'interazione dell'utente non deve far parte del flusso. Speriamo che questa guida aiuti a sciogliere ogni dubbio. La invitiamo a scoprire le nostre aree di competenza su https://www.doit.com/services/
employed
Should be "deployed" I think :)
Rispondi
retrieving
"r" should be upper case.
Rispondi
Il tema centrale di questo articolo. Permette di compiere azioni per conto degli utenti senza alcuna interazione da parte loro e opera in un flusso 2-Legged OAuth.
Formatting should not be bold letters.
Rispondi
Vedi tutte le risposte
di
[Modernizzare l'accesso alle applicazioni interne GKE: dalla VPN al gateway esterno IAP-Enabled\ \
13 gen 2025
di
[Costruire un'architettura AWS con MCP Servers e Strands Agents\ \
22 set 2025
di
[Fingerprint JA3 e JA4 in AWS WAF e oltre\ \
10 apr 2025
di
[Pattern di architettura VPC: approcci standalone vs centralizzati in AWS e GCP\ \
25 nov 2024
di
[Stanford ha demolito il prompt engineering con 8 parole (e non riesco a credere che abbia funzionato)\ \
19 ott 2025
[A clap icon25K\ \
[10 competenze indispensabili per Claude (e qualsiasi coding agent) nel 2026\ \
9 mar
[A clap icon1K\ \
[La fine dei dashboard e dei design system\ \
26 nov 2025
[A clap icon6.5K\ \
[Anthropic aggiunge la (nuova) Claude Code Auto Mode (addio Permission Mode)\ \
6 g fa
[A clap icon391\ \
di
[Probabilmente stai comprando la macchina sbagliata per l'AI locale — la verità su Mac Mini M4 vs Mini PC che nessuno…\ \
20 mar
[A clap icon1.1K\ \
di
[Ho smesso di usare ChatGPT per 30 giorni. Quello che è successo al mio cervello è stato sconvolgente.\