LinkedIn
Instagram
WhatsApp
Telegramma
Calendario di Google
Partecipare alla comunità SlackChiave API di Gmail vs OAuth: Perché non puoi saltare OAuth
Puoi usare una chiave API di Google per accedere a Gmail? Risposta breve: no. L'API di Gmail accede ai dati privati dell'utente, il che significa che ogni richiesta necessita del consenso esplicito dell'utente tramite OAuth 2.0. Questa guida copre l'esatto errore che vedrai se provi una chiave API, i 3 percorsi di autenticazione reali disponibili oggi e come connettere 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' }
);
È possibile utilizzare una chiave API con l'API di Gmail?
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 rispetto all'API di Gmail. Gmail accede ai dati privati degli utenti, il che richiede il consenso esplicito dell'utente tramite OAuth 2.0. Non esiste alcun flag, alcun header, alcun workaround che ti permetta di sostituire una chiave API con un token di accesso OAuth su alcun endpoint Gmail. La Gmail API restituirà un 401 Accesso Richiesto o 403 Limite giornaliero superato per uso non autenticato 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 le API pubbliche (Maps, Translate, dati pubblici di YouTube) che non accedono agli account utente. Gmail non è mai un dato pubblico.
OAuth 2.0 - Richiesto per l'API Gmail
OAuth 2.0 genera un token di accesso specifico per l'utente dopo che quest'ultimo ha esplicitamente concesso il consenso. L'API di Gmail legge quel token a 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 con le API di Google. Ecco la netta separazione.
Google Maps Platform Geocodifica, Indicazioni, Luoghi (nessun account utente necessario)
API di traduzione cloud - Traduzione di testi, rilevamento di lingue
API Dati di YouTube - Lettura di metadati video pubblici, canali, playlist
Cloud Vision / Natural Language - API di ML che elaborano i contenuti che carichi
Fatturazione + Monitoraggio quote - L'utilizzo di tutte le chiavi API viene conteggiato in base al tuo progetto
API Gmail - Lettura, invio o gestione della casella di posta di un utente
API di Google Calendar - Lettura o scrittura di eventi del calendario di qualsiasi utente
API di Google Drive - Accesso, caricamento o elenco di file di un utente
Amministratore di Google Workspace SDK Qualsiasi operazione con ambito 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 tale utente si autentichi tramite OAuth 2.0. Le chiavi API sono credenziali di progetto, non credenziali utente. Gmail API gestisce sempre dati 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 inventato da Google per rallentarti. È l'unico modo tecnicamente valido per concedere un accesso limitato, revocabile e verificabile ai dati privati dell'utente. I tre requisiti fondamentali di Gmail spiegano perché una chiave API non potrà mai sostituirlo.
Il consenso dell'utente è in 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 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 portano gli scope, precise dichiarazioni di ciò che l'app può e non può fare (sola lettura, invio, accesso completo). Gli utenti possono vedere esattamente quale accesso hanno concesso e revocarlo 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 del token protegge gli utenti
I token di accesso all'API di Gmail scadono (tipicamente dopo 1 ora). Ciò significa che un token rubato è inutile dopo una breve finestra. 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 di lunga durata senza un 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 memorizzate direttamente, queste hanno smesso di funzionare. OAuth 2.0 è l'unico meccanismo di autenticazione rimasto per l'API di Gmail, sia per le nuove integrazioni che per quelle migrate. Vedi l'annuncio ufficiale di Google.
Hai bisogno di gestire OAuth per più account Gmail nel tuo 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 tocchi mai un token.
Costruiscilo con UnipileI 3 Percorsi di Autenticazione Reali per l'API di Gmail
Una volta accettato che OAuth è inevitabile, la domanda diventa: quale percorso OAuth si adatta al tuo caso d'uso? Ci sono tre opzioni architettonicamente distinte, ognuna con diversi compromessi in termini di complessità, ambito utente e overhead di manutenzione.
| Criterio | ID client OAuth 2.0 (3 flussi) | Account di servizio + DWD | API Unificata (Unipile) |
|---|---|---|---|
| È necessario il consenso dell'utente? | |||
| Funziona con Gmail personale? | |||
| SaaS multi-tenant? | |||
| Gestione dei token | Il tuo codice memorizza e aggiorna i token Manutenzione elevata |
Chiave JSON dell'account di servizio Gestito dall'amministratore |
Unipile gestisce tutti i token Manutenzione zero |
| Recensione della schermata di consenso di Google? | |||
| Supporta anche Outlook + IMAP? | |||
| Tempo alla prima lettura dell'email | 2-4 ore di installazione App OAuth + ambiti + schermata di consenso |
1-2 ore di preparazione Amministratore dello spazio di lavoro richiesto |
Meno di 15 minuti Chiave API + account collegato |
| Il migliore per | App SaaS che si connettono alla Gmail degli utenti esterni | Strumenti per l'area di lavoro interna 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 collegano i propri account Gmail, il flusso di autorizzazione OAuth 2.0 con codice di autorizzazione è 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 gli ambiti sensibili. Per un approfondimento su Flusso OAuth per le API di posta elettronica in dettaglio, consulta la nostra guida dedicata.
Crea credenziali OAuth 2.0 nella Console Cloud di Google
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 genererà il tuo ID cliente e segreto del cliente.
Abilita l'API Gmail e dichiara gli ambiti
Vai su API e servizi > Schermata di consenso OAuth. Aggiungi gli ambiti Gmail di cui hai bisogno (ad esempio. gmail.solodlettura, gmail.inviaGli ambiti 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 la tua ID cliente, ambiti e uri_di_reindirizzamento. Dopo che hanno approvato, Google invia un codice di autorizzazione all'URI di reindirizzamento.
Scambiare il codice per i token e memorizzare il token di aggiornamento
POST il codice di autorizzazione all'endpoint dei token di Google. Ricevi un token_accesso (scade ~1h) e un token_di_aggiornamento (a lunga durata). Archivia il token di aggiornamento in modo sicuro: è così che ottieni nuovi token di accesso senza richiedere nuovamente 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 in Gmail OAuth self-gestito. Rotazione dei token, migrazioni di database, errori silenziosi su token scaduti, tutto questo viene gestito automaticamente quando si utilizza un fornitore unificato di API per email.
Integrazione con GmailPercorso 2 - Account di servizio + delega inter-dominio (interno di Workspace)
Se il tuo caso d'uso è interno a un'organizzazione Google Workspace, come ad esempio strumenti interni, automazione delle risorse umane o una dashboard di analisi delle email a livello aziendale, gli account di servizio 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. L'avvertenza fondamentale: questo percorso non funziona per gli indirizzi Gmail personali.
Gli account di servizio 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 utilizzare 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. Vedere 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 Vietato
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 casella di posta, sincronizzazione CRM (sola lettura) |
| gmail.invia | Invia email per conto dell'utente | Sensibile | Email transazionali lato utente, follow-up del CRM, strumenti di outreach |
| gmail.componi | Crea, leggi, aggiorna, elimina bozze; invia messaggi | Sensibile | Integrazioni con editor di posta elettronica, gestione bozze |
| modifica gmail | Leggi, invia, modifica (etichette, archivia) - non eliminare | 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 email completi, strumenti di backup, migrazione amministrativa |
| gmail.metadata | Solo metadati del messaggio (nessun corpo) | Non sensibile | Analisi sul volume delle email, schemi mittente/destinatario (nessun contenuto) |
Costruire un SaaS multi-tenant che necessita di gmail.modify o mail.google.com? La revisione dello scope limitato aggiunge settimane alla tua timeline di lancio. Con Unipile, salti completamente la revisione della schermata di consenso: l'app OAuth verificata di Unipile copre gli scope necessari per la tua integrazione.
Costruire con UnipileAlbero Decisionale: Quale Metodo di Autenticazione 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 tuoi utenti sono esterni (non dipendenti tuoi)?
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 completamente l'infrastruttura OAuth.
Strumento interno per la tua organizzazione Google Workspace
Tutti gli utenti appartengono allo stesso dominio Workspace (i tuoi dipendenti)?
Sì - solo account company.com. Nessun utente Gmail esterno.
Hai un amministratore di Workspace che può configurare il DWD?
Sì - accesso amministrativo 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 usano un mix di account Gmail, Outlook e IMAP?
Sì, non puoi prevedere a quale provider si connetterà ogni utente.
Vuoi evitare di eseguire integrazioni OAuth separate per ogni provider?
Sì, gestire Google OAuth + Microsoft OAuth + IMAP è troppa complessità.
Una 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 superato per uso non autenticato 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é La Gmail API non accetta chiavi API. Il 401 Accesso Richiesto errore significa che alla richiesta manca 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 dell'account di servizio o un token API unificato). Semplicemente aggiungendo ?key=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 silenziosa dei token di aggiornamento. 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. conti collegati. Ciò rimuove il processo di approvazione della schermata di consenso di Google e la complessità della gestione dei token dal tuo codebase, offrendoti Gmail, Outlook e IMAP sotto un'unica interfaccia unificata.
IT 
EN 
FR 
ES 
DE 
BR 
NL 
PL 
TR