LinkedIn
Instagram
WhatsApp
Telegramma
Calendario di Google
Partecipare alla comunità SlackChiave API Gmail vs OAuthPerché non puoi saltare OAuth
API di Gmail accede a dati privati dell'utente, il che significa che ogni richiesta necessita del consenso esplicito dell'utente tramite OAuth 2.0. Questa guida illustra l'errore esatto che si vedrà tentando di usare una chiave API, i 3 percorsi di autenticazione reali disponibili oggi e come collegare una casella di posta Gmail in 3 righe di codice utilizzando un API email unificata.
Chiave API di Gmail vs OAuth - il verdetto
// ----------------------------------------
// SBAGLIATO: la chiave API NON funziona con Gmail
const res = await fetch(
https://gmail.googleapis.com/gmail/v1/
users/me/messages?key=LA_TUA_CHIAVE_API`
);
// Restituisce: 401 Accesso Richiesto
// CORRETTO: token di accesso OAuth 2.0
const res = await fetch(
'https://gmail.googleapis.com/gmail/v1/users/me/messages',
{ headers: {
'Authorization': Portatore ${accessToken}`
} }
);
// OPPURE salta del tutto l'OAuth - usa Unipile
const posta elettronica = await unipilo.e-mail.list(
{ accountId: 'id-account-collegato' }
);
Puoi usare una chiave API con le Gmail API?
Se hai già lavorato con Google Cloud, sai che le chiavi API funzionano bene per Maps o Translate. Quindi, è naturale provare lo stesso approccio con Gmail. Non funzionerà. Ecco esattamente cosa succede e perché, più il verdetto in due frasi prima di approfondire.
No. Le chiavi API di Google non possono autenticarsi con l'API di Gmail. Gmail accede a dati privati degli utenti, il che richiede un consenso esplicito dell'utente tramite OAuth 2.0. Non esiste un flag, un header o una soluzione alternativa che consenta di sostituire una chiave API con un token di accesso OAuth su endpoint Gmail. L'API di Gmail restituirà un 401 Accesso richiesto o 403 Limite giornaliero per uso non autenticato superato errore ogni singola volta.
Chiave API - Funziona solo per dati pubblici
Una chiave API identifica il tuo progetto Google Cloud per la fatturazione e le quote. Funziona con API pubbliche (Maps, Translate, YouTube public data) che non accedono agli account utente. Gmail non è mai un dato pubblico.
OAuth 2.0 - Richiesto per l'API di Gmail
OAuth 2.0 genera un token di accesso specifico per l'utente dopo che l'utente ha esplicitamente concesso il consenso. L'API di Gmail legge quel token ad ogni richiesta per verificare sia l'identità dell'utente sia l'ambito di accesso approvato. Nessun token di accesso valido = nessuna risposta.
Cosa fa effettivamente una chiave API su Google Cloud (e cosa non fa)
Le chiavi API e i token OAuth sono due meccanismi distinti che risolvono due problemi diversi. Confonderli è uno degli errori più comuni quando si inizia a lavorare con le API di Google. Ecco la netta separazione.
Piattaforma Google Maps Geocodifica, Indicazioni stradali, Luoghi (non è necessario un account utente)
Traduzione Cloud API - Traduzione di testi, rilevamento di lingue
API Dati di YouTube - Lettura di metadati di video pubblici, canali, playlist
Cloud Vision / Linguaggio Naturale - API di machine learning che elaborano i contenuti che carichi
Fatturazione + Monitoraggio quote - Tutto l'uso delle chiavi API viene misurato rispetto al tuo progetto
API Gmail - Leggere, inviare o gestire la casella di posta di un utente
API di Google Calendar - Leggere o scrivere eventi del calendario di qualsiasi utente
API di Google Drive - Accesso, caricamento o elenco dei file di un utente
Google Workspace Admin SDK - Qualsiasi operazione con ambito di amministratore su un dominio
API Persone (dati utente) - Qualsiasi endpoint che accede ai contatti o al profilo di un utente
La regola è semplice: Se un'API accede ai dati dell'account di un utente, Google richiede che l'utente si autentichi tramite OAuth 2.0. Le chiavi API sono credenziali di progetto, non credenziali utente. L'API di Gmail riguarda sempre i dati dell'utente. Nessuna eccezione. Questa regola si applica indipendentemente dal fatto che la tua app sia pubblica o interna alla tua azienda.
Perché Gmail richiede OAuth 2.0
OAuth 2.0 non è un ostacolo burocratico che Google ha inventato per rallentarti. È l'unico modo tecnicamente valido per concedere accesso delimitato, revocabile e verificabile ai dati privati dell'utente. I tre requisiti fondamentali di Gmail spiegano perché una chiave API non può mai sostituirlo.
Il consenso dell'utente non è negoziabile
I dati di Gmail appartengono all'utente, non alla tua applicazione. OAuth 2.0 è il meccanismo con cui un utente dice esplicitamente "sì, questa applicazione può leggere la mia casella di posta in arrivo". Nessun flusso di consenso = nessun accesso. Questo è un requisito legale ai sensi del GDPR e una policy della piattaforma Google, non solo una restrizione tecnica.
Accesso limitato e revocabile
I token OAuth contengono ambiti (scope) - dichiarazioni precise di ciò che l'app può e non può fare (sola lettura, invio, accesso completo). Gli utenti possono vedere esattamente a quali accessi hanno acconsentito e revocarli in qualsiasi momento dalle impostazioni del loro Account Google. Una chiave API non concede nulla e non può revocare nulla a livello di utente.
La scadenza dei token protegge gli utenti
I token di accesso dell'API di Gmail scadono (tipicamente dopo 1 ora). Ciò significa che un token rubato è inutile dopo una breve finestra temporale. La tua app deve aggiornare silenziosamente i token utilizzando un token di aggiornamento, che a sua volta può essere revocato. Le chiavi API, al contrario, sono credenziali di progetto a lunga durata senza meccanismo di revoca a livello utente.
Google ha deprecato l'autenticazione username/password ("Basic Auth") per Gmail in Settembre 2024. Se hai integrazioni legacy che utilizzano credenziali archiviate direttamente, queste hanno smesso di funzionare. OAuth 2.0 è l'unico meccanismo di autenticazione rimanente per l'API di Gmail, sia per le nuove integrazioni che per quelle migrate. Vedi l'annuncio ufficiale di Google.
Hai bisogno di gestire l'OAuth per più account Gmail nella tua SaaS? Unipile gestisce la schermata di consenso, lo scambio di token e il refresh silenzioso per ogni account collegato, in modo che il tuo codice non venga mai a contatto con un token.
Costruiscilo con UnipileI 3 percorsi di autenticazione reali per Gmail API
Una volta accettato che OAuth è inevitabile, la domanda diventa: quale percorso OAuth si adatta al tuo caso d'uso? Esistono tre opzioni architettonicamente distinte, ciascuna con compromessi diversi in termini di complessità, ambito utente e overhead di manutenzione.
| Criterio | ID client OAuth 2.0 (3 passi) | Account di Servizio + DWD | API Unificata (Unipile) |
|---|---|---|---|
| È richiesto il consenso dell'utente? | |||
| Funziona con Gmail personale? | |||
| SaaS multi-tenant? | |||
| Gestione dei token | Il tuo codice memorizza e aggiorna i token Ad alta manutenzione |
Chiave JSON per account di servizio Gestito dall'amministratore |
Unipile gestisce tutti i token Manutenzione zero |
| Revisione della schermata di consenso di Google? | |||
| Supporta anche Outlook + IMAP? | |||
| Tempo alla prima lettura dell'email | 2-4 ore di configurazione App OAuth + ambiti + schermata di consenso |
1-2 ore di configurazione Amministratore dell'area di lavoro richiesto |
Meno di 15 minuti Chiave API + account collegato |
| Il migliore per | App SaaS che collegano Gmail di utenti esterni | Strumenti di workspace interni per la tua organizzazione | Qualsiasi caso d'uso di API email - nessuna operazione OAuth |
Percorso 1 - ID client OAuth 2.0 (SaaS multi-tenant)
Se stai costruendo un prodotto SaaS in cui i tuoi clienti colleganno i propri account Gmail, il flusso del codice di autorizzazione OAuth 2.0 è il percorso standard. Questo è il flusso a 3 vie: la tua app, Google e l'utente finale. Richiede la configurazione di un progetto Google Cloud e il superamento del processo di verifica della schermata di consenso per ambito sensibili. Per un approfondimento su Flusso OAuth per le API email in dettaglio, consulta la nostra guida dedicata.
Crea credenziali OAuth 2.0 nella Google Cloud Console
Vai su API e servizi > Credenziali > Crea credenziali > ID client OAuth. Scegli "Applicazione web". Configura gli URI di reindirizzamento autorizzati per la tua app. Questo genera il tuo ID cliente e segreto del cliente.
Abilita l'API di Gmail e dichiara i tuoi ambiti.
Vai a API e servizi > Schermata di consenso OAuth. Aggiungi gli ambiti Gmail di cui hai bisogno (ad es. gmail.solodlettura, gmail.invia). Ambienti sensibili e con restrizioni richiedono la verifica di Google, un processo che richiede giorni o settimane.
Reindirizza gli utenti all'URL di autorizzazione di Google
Quando un utente fa clic su "Connetti Gmail" nella tua app, reindirizzalo a Google con il tuo ID cliente, ambiti, e uri_di_reindirizzamento. Dopo che l'hanno approvata, Google restituisce un codice di autorizzazione al tuo URI di reindirizzamento.
Scambia il codice per i token e archivia il refresh token
Invia il codice di autorizzazione all'endpoint dei token di Google. Ricevi un token_accesso (scade ~1h) e un token_di_aggiornamento (a lunga conservazione). Conserva il token di aggiornamento in modo sicuro: è il modo in cui ottieni nuovi token di accesso senza richiedere nuovamente l'autorizzazione all'utente.
const google = require('googleapis');
const client oauth2 = new google.auth.OAuth2(
process.env.GMAIL_CLIENT_ID,
process.env.GMAIL_CLIENT_SECRET,
process.env.GMAIL_REDIRECT_URI
);
// Passaggio 1: Crea l'URL di autorizzazione
const authUrl = oauth2Client.generaUrlAutenticazione({
tipo_accesso: 'offline', // ottieni token di aggiornamento
ambito: [
'https://www.googleapis.com/auth/gmail.readonly',
'https://www.googleapis.com/auth/gmail.send'
]
});
// Passo 2: Scambia il codice per i token (nel tuo handler di callback)
async function gestisciCallback(codice) {
const { gettoni } = await oauth2Client.ottieniToken(codice);
oauth2Client.imposta credenziali(gettoni);
// Memorizza in modo sicuro i token.refresh_token nel tuo DB
return gettoni;
}
// Passaggio 3: usa il token di accesso per chiamare l'API di Gmail
async function elenca_messaggi(accessToken) {
const gmail = google.gmail({ versione: 'v1', auth: oauth2Client });
const res = await gmail.users.messages.list({ userId: 'me' });
return res.data.messaggi;
}La gestione dei token di aggiornamento su larga scala rappresenta il punto dolente di #1 n Gmail OAuth auto-gestito. La rotazione dei token, le migrazioni del database, i fallimenti silenziosi sui token scaduti, tutto questo viene gestito automaticamente quando si utilizza un fornitore unificato di API per email.
Crea la tua integrazione GmailPercorso 2 - Account di Servizio + delega a livello di dominio (Workspace Interno)
Se il tuo caso d'uso è interno a un'organizzazione Google Workspace – pensa a strumenti interni, automazione HR o una dashboard di analisi delle email a livello aziendale – i service account con delega a livello di dominio (DWD) ti consentono di accedere alle caselle di posta senza flussi di consenso per utente. Un amministratore di Workspace concede la delega una sola volta. Avvertenza critica: questo percorso non funziona per gli indirizzi Gmail personali.
I service account non possono accedere agli account Gmail personali (@gmail.com). DWD funziona solo all'interno di un dominio Google Workspace. Se i tuoi utenti si registrano con indirizzi Gmail personali, devi utilizzare il Percorso 1 (ID client OAuth) o il Percorso 3 (API unificata). Il tentativo di DWD su un account personale restituisce un errore 403.
Amministratore dello spazio di lavoro richiesto: DWD deve essere configurato da un amministratore di Google Workspace su admin.google.com. Non puoi farlo come sviluppatore senza accesso amministrativo.
Sicurezza delle chiavi JSON: La chiave JSON dell'account di servizio è una credenziale a lunga durata. Trattala come una chiave privata: ruotala regolarmente e non inserirla mai nel controllo sorgente.
Dichiarazione di ambito richiesta: L'amministratore deve approvare esplicitamente ogni ambito Gmail durante la configurazione di DWD. Non è possibile richiedere ambiti in fase di esecuzione. Vedi Guida DWD di Google.
from google.oauth2 import account di servizio
from googleapiclient.discovery import costruire
# Percorso della chiave JSON del tuo account di servizio
FILE_ACCOUNT_SERVICE = 'service-account.json'
SCOPI = [
'https://www.googleapis.com/auth/gmail.readonly'
]
# Assumere l'identità di un utente nel dominio del proprio Workspace
# (la delega a livello di dominio deve essere abilitata dall'amministratore)
def get_gmail_service(indirizzo_email_utente):
crediti = service_account.Credentials.dal_file_account_di_servizio(
FILE_ACCOUNT_SERVIZIO,
ambiti=SCOPI
)
# Si tratta di una delega a livello di dominio: assumere l'identità dell'utente
credenziali delegate = credenziali.con_soggetto(indirizzo_email_utente)
return costruire('gmail', 'v1', credenziali=credenziali_delegate
# Elenco dei messaggi per un utente dell'area di lavoro
servizio = get_gmail_service('alice@yourcompany.com')
risultati = servizio.utenti().messaggi().list(
ID utente='me'
).eseguire()Percorso 3 - API Email Unificata (Salta il Boilerplate OAuth)
Se il tuo obiettivo è leggere, inviare o sincronizzare email in un'applicazione SaaS di produzione e preferisci non dedicare cicli di ingegneria alla gestione dell'infrastruttura OAuth, un'API email unificata come Unipile astrae l'intero livello di autenticazione. come funziona la sincronizzazione delle email sotto il cofano, o vai direttamente al codice. Questo approccio ti offre anche Gmail, Outlook e IMAP sotto un'unica API: nessuna integrazione separata per ogni provider.
Nessuna configurazione di Google Cloud richiesta
Nessun ID client OAuth, nessuna schermata di consenso, nessuna revisione dell'ambito con Google. L'app OAuth verificata di Unipile gestisce l'autorizzazione dell'utente.
Rotazione automatica dei token
I get token e di refresh token sono gestiti interamente da Unipile. Il tuo database non memorizza mai un token OAuth di Google.
Funziona per Gmail personale + Outlook + IMAP
Un'API, tre universi di provider. Quando tu confrontare fornitori di API di sincronizzazione email, il supporto cross-provider è un elemento di differenziazione importante.
Consegna webhook per nuovi messaggi
Invece di interrogare l'API di Gmail, Unipile invia in tempo reale gli eventi delle nuove email al tuo endpoint webhook, per account collegato.
// 3 righe per leggere una casella Gmail via Unipile
// Nessuna configurazione OAuth, nessuna gestione dei token
const {UnipileClient } = require('unipile-node-sdk');
const client = new UnipileClient({
token: process.env.UNIPILE_API_KEY
});
// Elenca le email da un account Gmail collegato
// accountId = l'ID dell'account collegato a Unipile
const e-mail = await client.email.elenca_messaggi({
account_id: 'id-account-collegato',
limite: 20
});
// Invia una e-mail per conto dell'account collegato
await client.email.inviare({
account_id: 'id-account-collegato',
to: 'recipient@example.com',
oggetto: 'Ciao da Unipile',
body: 'Nessun token OAuth in vista.'
});
// Funziona identicamente per Outlook e IMAP
// Basta scambiare account_idImplementa la tua integrazione Gmail senza operazioni OAuth
Inizia con il Guida completa all'integrazione con l'API di Gmail, quindi esegui il deploy con Unipile come tuo livello di autenticazione e sincronizzazione.
Errori comuni quando si tenta di utilizzare una chiave API con Gmail
Se sei arrivato a questo articolo perché la tua chiamata all'API di Gmail sta fallendo, ecco i due errori che incontrerai e cosa significa ciascuno di essi, con il corpo della risposta grezza in modo da poterli riconoscere istantaneamente.
Hai inviato una richiesta all'API di Gmail con una chiave API (?chiave=AIza...) o senza alcuna autorizzazione. L'API di Gmail richiede un token di accesso OAuth 2.0 valido nell' Autorizzazione: Bearer intestazione. Questo è il primo errore che vedrai Quando si sperimenta per la prima volta con una chiave API.
Correggere: Implementa uno dei 3 percorsi di autenticazione sopra indicati. La chiave API non è la soluzione: è necessario un token di accesso OAuth.
HTTP/1.1 401 Non autorizzato
Content-Type: application/json
"code": 401,
"messaggio": "La richiesta è priva di credenziali di autenticazione obbligatorie. Atteso token di accesso OAuth 2, cookie di accesso o altra credenziale di autenticazione valida. Vedere https:// developers.google.com/ identity/sign-in/web/...",
"stato": "NON AUTENTICATO",
"errori": [{
"messaggio": "Accesso richiesto",
"dominio": "googleapis.com",
"motivo": "richiesto",
"posizione": "Authorization",
"tipoPosizione": "header"
}]
}
}Dopo richieste non autenticate ripetute (anche con una chiave API), il sistema di quote di Google blocca ulteriori chiamate non autenticate dal tuo IP o progetto. Questo non è un limite di frequenza per gli utenti autenticati - significa specificamente le tue richieste non sono mai state autenticate e hai esaurito il piccolo bonus gratuito per le chiamate anonime.
Correggere: Come sopra: il tuo approccio con la chiave API non funzionerà mai. Utilizza i token di accesso OAuth 2.0. Questo errore scomparirà una volta che le tue richieste conterranno un token Bearer valido.
HTTP/1.1 403 Proibito
Content-Type: application/json
"code": 403,
"message": "Limite giornaliero per
l'uso non autenticato superato.
L'uso continuato richiede
la registrazione.",
"status": "RESOURCE_EXHAUSTED",
"errors": [{
"message": "Limite giornaliero per
l'uso non autenticato
superato.",
"domain": "usageLimits",
"reason":
"dailyLimitExceededUnreg"
}]
}
}Ambito delle API di Gmail che ti serviranno effettivamente
Una volta accettato che OAuth è necessario, la selezione dell'ambito (scope) è la prossima decisione critica. Google classifica gli ambiti di Gmail in tre livelli in base alla sensibilità dei dati che espongono. Richiedere più di quanto sia necessario innesca un processo di verifica più lungo e, in alcuni casi, una valutazione completa della sicurezza da parte di Google.
Ambiti sensibili (giallo) richiede a Google di rivedere la tua schermata di consenso OAuth e di verificare la privacy policy della tua app. Ambito ristretto (rosso) richiedono una valutazione formale della sicurezza, una dimostrazione video e, a volte, un audit di sicurezza di terze parti. Pianifica un minimo di 2-6 settimane per l'approvazione di un ambito ristretto. Se utilizzi Unipile come livello di autenticazione, questo processo di verifica ricade su Unipile, non sulla tua app.
| Ambito | Livello di accesso | Livello | Caso d'uso |
|---|---|---|---|
| gmail.solodlettura | Leggi tutti i messaggi, thread, etichette, impostazioni | Sensibile | Analisi delle email, strumenti di audit della posta in arrivo, sincronizzazione CRM (sola lettura) |
| gmail.invia | Invia email per conto dell'utente | Sensibile | Email transazionali lato utente, follow-up CRM, strumenti di outreach |
| gmail.componi | Creare, leggere, aggiornare, eliminare bozze; inviare messaggi | Sensibile | Integrazioni con editor di posta elettronica, gestione delle bozze |
| modifica gmail | Leggi, invia, modifica (etichette, archivio) - nessuna cancellazione | Restricted | Gestione completa della casella di posta, sincronizzazione CRM con scrittura, flussi di lavoro di archiviazione |
| mail.google.com | Accesso completo - lettura, scrittura, eliminazione, impostazioni | Restricted | Client di posta elettronica completi, strumenti di backup, migrazione amministratore |
| gmail.metadata | Solo metadati del messaggio (nessun corpo) | Non sensibile | Analisi del volume delle email, schemi mittente/destinatario (senza contenuto) |
Costruire un SaaS multi-tenant che necessita di gmail.modify o mail.google.com? La revisione dello scopo limitato aggiunge settimane alla tua tempistica di lancio. Con Unipile, salti completamente la revisione della schermata di consenso: l'app OAuth verificata di Unipile copre gli ambiti necessari alla tua integrazione.
Costruire con UnipileAlbero decisionale: quale metodo di autenticazione scegliere per il tuo caso d'uso?
Rispondi a tre domande e saprai esattamente quale percorso di autenticazione dell'API di Gmail si applica al tuo progetto. Non esiste una risposta universale: ogni percorso risolve un problema diverso. Per la guida completa Guida completa all'integrazione con l'API di Gmail, continua all'hub di Gmail. Per l'equivalente per Outlook / Microsoft 365, consulta la nostra guida OAuth di Microsoft Graph.
App SaaS in cui i clienti collegano la propria Gmail
I vostri utenti sono esterni (non dipendenti)?
Sì, sono i tuoi clienti con account Gmail personali o Google Workspace.
Hai bisogno di supportare molti domini Google diversi?
Sì - multi-tenant. Ogni utente collega il proprio account.
Oppure Percorso 3 (API unificata) per saltare del tutto l'infrastruttura OAuth.
Strumento interno per la tua organizzazione Google Workspace
Tutti gli utenti appartengono allo stesso dominio Workspace (i vostri dipendenti)?
Sì - solo account company.com. Nessun utente Gmail esterno.
Hai un amministratore di Workspace in grado di configurare DWD?
Sì - accesso amministratore disponibile in admin.google.com.
Nessun flusso di consenso per utente. L'amministratore delega una volta.
App SaaS che necessita di Gmail + Outlook + IMAP sotto un'unica API
I tuoi utenti hanno un mix di account Gmail, Outlook e IMAP?
Sì, non puoi prevedere a quale provider si connetterà ciascun utente.
Vuoi evitare di gestire integrazioni OAuth separate per ogni provider?
Sì, gestire Google OAuth, Microsoft OAuth e IMAP è troppo complesso.
Una sola chiave API. Gmail, Outlook, IMAP. Nessuna operazione OAuth.
Inizia oggi stesso a creare la tua integrazione con Gmail
Qualunque sia il percorso che scegli, Unipile ti offre un panoramica API email unificata per capire l'architettura prima di impegnarti in un approccio. Oppure salta direttamente alla dashboard e collega il tuo primo account in pochi minuti.
Domande frequenti
Le domande più comuni sull'autenticazione dell'API Gmail, API key vs token OAuth e come accedere a Gmail programmaticamente senza gestire tu stesso OAuth.
Posso usare una chiave API di Google per accedere a Gmail?
No. Le chiavi API di Google funzionano solo per API pubbliche non specifiche per l'utente, come Maps, Translate o YouTube Data (contenuti pubblici). Gmail API accede dati della casella di posta privata dell'utente, che richiede il consenso esplicito dell'utente tramite OAuth 2.0. L'invio di una richiesta all'API di Gmail utilizzando solo una chiave API restituisce un 401 Accesso richiesto o 403 Limite giornaliero per uso non autenticato superato errore - ogni volta, senza eccezioni.
L'API di Gmail richiede OAuth 2.0?
Sì, sempre. L'accesso all'API di Gmail è un accesso ai dati dell'utente, il che significa che ogni richiesta deve essere legata a un utente autenticato che ha concesso il consenso tramite un flusso OAuth 2.0. Non esiste un workaround: niente chiavi API, niente autenticazione di base (deprecato settembre 2024), nessun header magico. I tre percorsi di autenticazione supportati sono: ID client OAuth 2.0 (multi-tenancy), Account di servizio con delega a livello di dominio (solo Workspace) e un'API email unificata come Unipile che gestisce lo strato OAuth per te.
Qual è la differenza tra una chiave API e un ID client OAuth su Google Cloud?
Un Chiave API identifica il tuo progetto Google Cloud ai fini di fatturazione e quote. Funziona solo per le API che servono dati pubblici (Maps, Translate, ecc.). Un ID client OAuth viene utilizzato per avviare un flusso di consenso in cui un utente reale approva l'accesso della tua app al proprio account. L'ID client OAuth genera il token di accesso e il token di aggiornamento che l'API di Gmail accetta effettivamente. Questi sono due meccanismi completamente diversi: uno identifica un progetto, l'altro autentica un utente.
Uno service account può leggere Gmail senza il consenso dell'utente?
Solo se Delega a livello di dominio (DWD) è abilitata da un amministratore di Google Workspace. Un account di servizio da solo non può accedere a nessuna casella di posta Gmail. Con DWD configurato, l'account di servizio può impersonare qualsiasi utente dell'organizzazione e accedere alla propria casella di posta senza consenso interattivo. Limitazione critica: questo funziona solo per account Google Workspace (aziendali). Non funziona per indirizzi Gmail personali (@gmail.com). Vedi Documentazione ufficiale DWD di Google.
Perché l'API di Gmail restituisce "Login Required" con la mia chiave API?
Perché Gmail API non accetta chiavi API. Il 401 Accesso richiesto errore significa che la richiesta non dispone di un token di accesso OAuth 2.0 valido in Authorization header. Gmail API si aspetta: Autorizzazione: Bearer {access_token} - dove il token di accesso è stato ottenuto tramite un flusso OAuth 2.0 (codice di autorizzazione, JWT account di servizio o token API unificato). Semplicemente aggiungendo ?chiave=LA_TUA_CHIAVE_API All'URL dell'API di Gmail non funzionerà e restituirà 401 o 403.
Esiste un modo per utilizzare l'API di Gmail senza dover gestire l'OAuth autonomamente?
Sì. Un'API email unificata come Unipile gestisce l'intero livello OAuth: la schermata di consenso, lo scambio di token e la rotazione dei token di aggiornamento silenziosi. La tua applicazione non memorizza né gestisce mai token di accesso o token di aggiornamento. Chiami l'API Unipile con la tua chiave API e Unipile gestisce tutte le comunicazioni OAuth con Google per tuo conto. account collegati. Ciò rimuove il processo di approvazione della schermata di consenso di Google e la complessità della gestione dei token dal tuo codice sorgente e ti offre Gmail, Outlook e IMAP sotto un'unica interfaccia unificata.
IT 
EN 
FR 
ES 
DE 
BR 
NL 
PL 
TR