LinkedIn
Instagram
WhatsApp
Telegramma
Calendario di Google
Partecipare alla comunità SlackAPI OAuth Email: Autentica Caselle di Posta degli Utenti Il modo giusto
Smetti di memorizzare password. Un'API email basata su OAuth consente alla tua app di accedere alle caselle di posta degli utenti in modo sicuro, utilizzando token revocabili e con ambito limitato da provider Gmail, Outlook e IMAP. Questa guida copre ogni flusso OAuth, ogni ambito, ogni insidia e come pubblicare in 5 minuti con un layer di autenticazione unificato e ospitato.
// Connetti qualsiasi casella di posta dell'utente tramite OAuth - 1 chiamata API
const response = await fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: 'POST',
headers: {
'X-API-KEY': 'CHIAVE_API_TUA',
'Content-Type': 'application/json'
},
body: JSON.stringify({
tipo: 'GOOGLE', // o MICROSOFT, IMAP
nome 'utente_123'
})
}
);
const { url } = await risposta.json();
// Reindirizza l'utente all'URL - OAuth gestito da Unipile
Cos'è un'API email OAuth?
Un Email API OAuth è un'interfaccia programmatica che consente alla tua applicazione di accedere alle caselle di posta degli utenti tramite token OAuth 2.0, senza mai gestire o archiviare la password dell'utente. Anziché richiedere le credenziali agli utenti, li reindirizzi attraverso la schermata di consenso del provider, ricevi un token di accesso di breve durata e lo utilizzi per leggere, inviare o sincronizzare e-mail per loro conto. La distinzione è importante: si tratta dell'accesso a caselle postali di proprietà dell'utente (Gmail, Outlook, email personale), non inviare email transazionali tramite servizi di inoltro SMTP come SendGrid.
Un Email API OAuth è una combinazione di un flusso di autorizzazione OAuth 2.0 (per autenticare un utente e ottenere accesso delegato) e di un'API di posta elettronica (per leggere, inviare, cercare o sincronizzare la mailbox di quell'utente). Il livello OAuth genera un token di accesso revocabile, limitato nello scopo e firmato crittograficamente. L'API di posta elettronica utilizza quel token per interagire con Gmail, Outlook o qualsiasi mailbox compatibile con IMAP, il tutto senza mai conoscere la password dell'utente.
- Memorizza password in chiaro o crittografate nel tuo database
- Accesso completo alla casella di posta - nessun controllo sull'ambito
- Bloccato da Google/Microsoft dal 2026
- Responsabilità GDPR/SOC2 per l'archiviazione delle credenziali
- Nessuna memorizzazione di password - solo token di breve durata
- Ambienti granulari - di sola lettura, di invio o completi
- Revocabile in qualsiasi momento dall'utente
- Conforme al GDPR, SOC2
Perché OAuth ha sostituito l'accesso via email basato su password
Utilizzare IMAP con nome utente e password era il modo standard per accedere programmaticamente alle e-mail degli utenti. Quell'era è finita. Google ha deprecato l'autenticazione di base per Gmail nel 2022 e Microsoft ha completato lo spegnimento dell'autenticazione di base per Exchange Online nell'ottobre 2022, con la completa eliminazione dei protocolli rimanenti nel 2026. Se la tua applicazione si basa ancora sull'accesso IMAP basato su password, è già rotta o si romperà presto.
I token OAuth hanno una durata limitata (tipicamente 1 ora) e sono limitati nello scope. Anche se trapelano, non possono essere utilizzati per accedere come utente, modificare la loro password o accedere ad altri servizi. Non si toccano mai le credenziali dell'utente.
Microsoft ha completato il ritiro dell'autenticazione di base per Exchange Online e IMAP legacy nel 2026. Qualsiasi applicazione che utilizza ancora nome utente + password per accedere alle cassette postali di Outlook o Microsoft 365 riceverà errori 401 Non autorizzato.
Memorizzare le password degli utenti, anche se sottoposte ad hashing, crea una responsabilità normativa. Il principio di minimizzazione dei dati del GDPR richiede di non raccogliere ciò che non è necessario. Gli auditor SOC2 segnalano la memorizzazione delle credenziali.
Critico Google App Passwords e i protocolli legacy di Microsoft non sono più sufficienti per le applicazioni di produzione. Se stai costruendo un prodotto che accede alle caselle di posta degli utenti, un Email API OAuth non è facoltativo: è l'unico percorso conforme per il futuro nel 2026.
Come funziona OAuth per le API di posta elettronica (passo dopo passo)
Il flusso di codice di autorizzazione è il flusso standard di OAuth 2.0 per le applicazioni lato server che necessitano di accedere all'email dell'utente. Comprenderlo end-to-end ti aiuta a implementarlo correttamente, a risolvere i problemi di token e a spiegare il flusso al tuo team di sicurezza.
Costruisci un URL con il tuo ID cliente, a uri_di_reindirizzamento, la richiesta ambito, un caso stato parametro (protezione CSRF) e tipo_di_risposta=codice. L'utente viene reindirizzato alla schermata di consenso di Google o Microsoft.
La schermata di consenso mostra il nome della tua app, il logo e le autorizzazioni esatte che hai richiesto. L'utente approva (concede il consenso) o nega. Richiedere troppi ambiti in questa fase è la causa più comune di rifiuto del consenso.
Dopo il consenso, il fornitore reindirizza al tuo uri_di_reindirizzamento di breve durata codice parametro (valido per circa 10 minuti). Verifica stato il parametro corrisponde a quello che hai inviato per prevenire attacchi CSRF.
POST server-to-server all'endpoint del token con il tuo ID cliente, segreto del cliente, il codice, e grant_type=authorization_code. ricevi un token_accesso e (se hai richiesto l'accesso offline) un token_di_aggiornamento.
Passare il token di accesso in Autorizzazione: Bearer intestazione su ogni richiesta API. Quando scade (tipicamente dopo 1 ora), utilizza il token di aggiornamento per ottenere un nuovo token di accesso senza interazione dell'utente.
Token di accesso vs token di aggiornamento: ciclo di vita
Valido per 1 ora (Google) o 1 ora (Microsoft). Passato nell'intestazione Authorization su ogni chiamata API. Quando scade, la tua chiamata API email OAuth restituisce un errore 401 - il segnale per aggiornare.
Valido fino a revoca (Google) o 90 giorni di inattività (Microsoft). Mai inviato a endpoint API - usato solo server-to-server per ottenere nuovi token di accesso. Deve essere crittografato a riposo.
Costruisci un flusso OAuth unificato in pochi minuti
Salta la struttura di autorizzazione per-provider. Una chiamata API di Unipile sostituisce tre integrazioni OAuth.
Flussi OAuth per Fornitore: Google e Microsoft
Google e Microsoft implementano OAuth 2.0 in modo diverso: endpoint di autorizzazione diversi, ambiti diversi, endpoint di token diversi e processi di verifica diversi. IMAP è il fallback basato su credenziali per i provider senza OAuth standardizzato. Ecco cosa devi sapere per ogni caso.
L'implementazione OAuth di Google utilizza il flusso di codice di autorizzazione standard. L'endpoint del token è https://oauth2.googleapis.com/token. La complessità critica è Google CASA (Cloud Application Security Assessment): una volta che la tua app supera i 100 utenti, devi superare una revisione di sicurezza. Per casi d'uso sensibili come modifica gmail o gmail.solodlettura, la verifica dell'app è richiesta prima dell'uso in produzione. Per un completo Gmail API un'immersione profonda, vedere la nostra guida dedicata. I dettagli di implementazione sono nel Google OAuth docs Unipile.
Codice di autorizzazione # per l'accesso a Gmail + token di aggiornamento
ricciolo -X POST https://oauth2.googleapis.com/token \
-d "codice=CODICE_AUTENTICAZIONE" \
-d "client_id=IL_TUO_CLIENT_ID" \
-d "client_secret=IL_TUO_CLIENT_SECRET" \
-d "redirect_uri=https://yourapp.com/callback" \
-d "grant_type=authorization_code"
Risposta #: { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }
Microsoft utilizza la sua Piattaforma di Identità (precedentemente Azure AD v2). L'endpoint del token è https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. La verifica dell'editore è richiesta prima che la tua app API email OAuth possa richiedere ambiti di posta elettronica sensibili in produzione. Microsoft ha deprecato l'autenticazione di base per tutti i protocolli di Exchange Online: OAuth è obbligatorio. Vedi il nostro Guida completa a Microsoft Graph per le email per tutti i dettagli, e il Documentazione Microsoft OAuth di Unipile per riferimento di implementazione.
Codice di scambio # per i token OAuth di Microsoft
ricciolo -X POST https://login.microsoftonline.com/common/oauth2/v2.0/token \
-d "codice=CODICE_AUTENTICAZIONE" \
-d "client_id=IL_TUO_CLIENT_ID" \
-d "client_secret=IL_TUO_CLIENT_SECRET" \
-d "redirect_uri=https://yourapp.com/callback" \
-d "grant_type=authorization_code" \
-d "scope=https://graph.microsoft.com/Mail.Read offline_access"
Risposta #: { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }
IMAP non è un provider OAuth: è un protocollo che si autentica con nome utente/password, oppure password per app (come una Gmail App Password o una password generata da iCloud). È il fallback per server di posta personalizzati, domini aziendali non su Microsoft 365 e qualsiasi provider senza un flusso OAuth standardizzato. XOAUTH2 è esistito come estensione SASL IMAP per un piccolo numero di provider, ma è stato in gran parte abbandonato: Yahoo ha interrotto la sua implementazione proprietaria nel 2022. Per la maggior parte delle distribuzioni IMAP, Unipile si autentica direttamente con le credenziali. Vedi il completo Guida all'integrazione IMAP per la configurazione del server e i dettagli di autenticazione.
import base64, imaplib
# Generazione della stringa XOAUTH2 dal token di accesso OAuth
def build_xoauth2(email_utente, token_di_accesso):
auth_str = f"utente={user_email}\x01auth=Bearer {access_token}\x01\x01"
return base64.b64encode(auth_str.encode()).decode()
#: connessione tramite IMAP con XOAUTH2
Connessione = imaplib.IMAP4_SSL("imap.mail.yahoo.com")
auth_str = build_xoauth2("user@yahoo.com", access_token)
conn.autenticare("XOAUTH2", lambda x: auth_str)La complessità nascosta di OAuth multi-provider
Implementare un'API di posta elettronica OAuth per un provider richiede alcuni giorni. Implementarla correttamente per Gmail, Outlook e IMAP, con gestione dei token, gestione degli errori e conformità di livello produttivo, richiede tipicamente da 4 a 8 settimane di tempo di ingegneria. Ecco perché.
Google Cloud Console, Azure Portal e Yahoo Developer Network sono 3 dashboard completamente diverse con UX differenti, flussi di registrazione delle app differenti e requisiti di verifica differenti. Qualsiasi rotazione delle credenziali tocca tutte e 3.
Gli ambiti sensibili di Gmail (inclusi gmail.solodlettura) sono limitati a 100 utenti fino al superamento di una valutazione CASA di livello 2. Ciò comporta un laboratorio autorizzato da CASA, un test di penetrazione e una revisione formale della sicurezza; in genere occorrono dalle 6 alle 12 settimane e il costo varia da 10.000 a 25.000 dollari.
Microsoft richiede la verifica dell'editore per le app che richiedono ambiti di posta sensibili. Senza di essa, gli utenti vedono un avviso rosso "editore non verificato" nella schermata di consenso. Il processo di verifica richiede un account Microsoft Partner Network attivo con un dominio verificato.
I token di aggiornamento di Google scadono dopo 6 mesi di inattività (o immediatamente se l'utente li revoca). I token di Microsoft scadono dopo 90 giorni di inattività. I token XOAUTH2 di Yahoo/IMAP hanno durata specifica del provider. Il tuo livello di gestione dei token deve gestirli tutti e 3 in modo diverso.
Google, Microsoft e Yahoo visualizzano le schermate di consenso in modo diverso: branding diverso, descrizioni dell'ambito diverse, schemi UI diversi. I tuoi utenti vedono 3 flussi diversi a seconda del loro provider di posta elettronica, creando un'esperienza utente incoerente e tassi di abbandono più elevati.
Gli endpoint OAuth cambiano. I nomi degli scope vengono deprecati. Vengono aggiunti nuovi requisiti di sicurezza. Ogni provider annuncia modifiche incompatibili in tempi diversi. Qualcuno nel tuo team deve monitorare 3 blog di provider, 3 changelog e 3 calendari di conformità, indefinitamente.
Saltare completamente la complessità di OAuth
Autenticazione ospitata, gestione degli scope, gestione dei refresh. Unipile gestisce tutto questo in modo che tu possa concentrarti sul tuo prodotto.
Architettura API OAuth per Email: 3 approcci a confronto
Esistono 3 architetture per la creazione di uno strato API e-mail OAuth. Ognuna ha un costo di implementazione, un carico di manutenzione e un profilo di sicurezza fondamentalmente diversi. La scelta giusta dipende dal fatto che la connettività e-mail sia il tuo prodotto principale o una funzionalità che stai implementando a fianco del tuo prodotto principale.
| Dimensione | Provider OAuth Diretto (x3) | Gateway OAuth Self-Hosted | OAuth Ospitato Unificato (Unipile) Consigliato |
|---|---|---|---|
| Tempo alla prima casella collegata | 3-7 giorni (per fornitore) | 2-4 settimane | 5 minuti |
| Flussi OAuth da implementare | 3 flussi separati | 3 flussi + logica di routing | endpoint host di un link |
| recensione di Google CASA | Ci pensi tu (6-12 settimane, $10k+) | Te ne occupi tu | Gestito da Unipile |
| Verifica di Microsoft Publisher | Te ne occupi tu | Te ne occupi tu | Gestito da Unipile |
| Gestione del rinnovo del token | 3 strategie per costruire | Personalizzato per provider | Automatico, trasparente |
| API per inviare/leggere email | 3 API diverse | Strato di astrazione richiesto | 1 API REST unificata |
| Webhook su nuove email | Push/pull per provider | Personalizzato | Eventi webhook unificati |
| Conformità SOC2 / GDPR | La vostra responsabilità | La vostra responsabilità | Unipile è certificato SOC2 |
| Manutenzione in corso | Alto (3 log delle modifiche del provider) | Alto | Zero - gestito da Unipile |
| Il migliore per | Prodotti nativi di posta elettronica, a fornitore singolo | Grandi squadre con infrastruttura dedicata | Qualsiasi squadra che spedisce velocemente |
Costruire vs Comprare: API Email OAuth Ospitata in 5 Minuti
Invece di costruire 3 flussi OAuth separati, Unipile fornisce un link di autenticazione ospitato che gestisce per te OAuth di Google, Microsoft Identity e IMAP OAuth. La tua app genera un link, reindirizza l'utente e riceve un webhook quando la casella di posta è collegata. L'API email OAuth è quindi immediatamente utilizzabile: nessuna configurazione da console, nessuna revisione CASA, nessuna logica di aggiornamento token da creare.
Passaggio 1: Genera un collegamento di autenticazione ospitato
Una chiamata API per creare una sessione di autenticazione ospitata. Specificare il tipo di provider e un nome per l'account. Unipile restituisce un URL a cui reindirizzare l'utente alla schermata di consenso OAuth.
// Collega utente Gmail tramite API email OAuth ospitata da Unipile
const response = await fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: 'POST',
headers: {
'X-API-KEY': 'LA_TUA_CHIAVE_API_UNIPILE',
'Content-Type': 'application/json'
},
body: JSON.stringify({
tipo: 'GOOGLE',
nome 'user_alice_123',
success_redirect_url: 'https://yourapp.com/connesso',
failure_redirect_url: 'https://yourapp.com/errore'
})
}
);
const { url, oggetto } = await risposta.json();
// Reindirizza l'utente all'URL - Unipile gestisce il consenso OAuth
finestra.location.href = url;Passaggio 2: Connetti un utente di Outlook
Stessa endpoint, stesso schema. Cambia tipo a MICROSOFT. Nessun portale Azure, nessuna verifica dell'editore da gestire da parte tua.
import richieste
#: collegamento di un utente Outlook tramite l'API e-mail OAuth di Unipile
response = richieste.posta(
"https://api6.unipile.com:13226/api/v1/hosted/accounts/link",
intestazioni={"X-API-KEY": "LA_TUA_CHIAVE_API_UNIPILE"},
json={
"tipo": "MICROSOFT",
"nome": "utente_bob_456",
"url_reindirizzamento_successo": "https://yourapp.com/connected"
}
)
auth_url = response.json()["url"]
# Reindirizzamento a auth_url - Flusso di autenticazione Microsoft gestito da UnipilePassaggio 3: Ricevere il webhook su account.connected
Dopo il consenso OAuth, Unipile invia un webhook al tuo endpoint. Il payload dell'evento include il nuovo account_id - che memorizzi e utilizzi per tutte le successive leggi email API e API per inviare email chiamate.
Evento webhook: Quando un utente completa OAuth, Unipile invia un conto.connesso evento al tuo URL del webhook. Il payload contiene account_id (salvalo), il provider (GOOGLE / MICROSOFT / IMAP) e l'indirizzo email collegato. Questo è l'unico stato che devi conservare: Unipile gestisce internamente tutti i token OAuth.
Salta l'implementazione di OAuth di 8 settimane. Collega le caselle di posta in pochi minuti.
L'API email OAuth ospitata da Unipile gestisce Google CASA, Microsoft Publisher Verification, XOAUTH2 e l'aggiornamento dei token per tutti i provider. I tuoi utenti collegano la loro casella di posta tramite un singolo flusso ospitato, ottenendo un'API unificata per leggere, inviare e sincronizzare.
Gestione dei token OAuth: aggiorna, revoca, ruota
La gestione dei token è la parte più impegnativa a livello operativo nella creazione di un'API email OAuth. I token di accesso scadono, i token di aggiornamento vengono revocati dagli utenti e il tuo sistema deve gestire tutto questo in modo efficiente, o rischiare che i tuoi utenti perdano l'accesso alle loro caselle di posta in modo silenzioso.
Migliori pratiche per l'archiviazione dei token
- Cripta i token di aggiornamento a riposo usando AES-256 o un KMS cloud (AWS KMS, GCP Cloud KMS, Azure Key Vault). Non memorizzarli mai in chiaro nel tuo database.
- Non registrare mai token di accesso o token di aggiornamento. Sistemi di logging strutturato come Datadog o Splunk dovrebbero avere campi token mascherati o redatti.
- Archivia i token in un deposito di segreti dedicato (Vault, AWS Secrets Manager) anziché nel database principale dell'applicazione, per minimizzare il raggio di azione in caso di compromissione del DB.
- Implementa la rotazione dei token: quando ricevi un nuovo token di aggiornamento in una chiamata di aggiornamento (alcuni provider emettono nuovi token di aggiornamento ad ogni utilizzo), invalida immediatamente quello vecchio.
Gestire i fallimenti di aggiornamento in modo appropriato
Quando un token di aggiornamento scade o viene revocato, la tua chiamata di aggiornamento restituisce un errore 400 o 401. La tua API di posta elettronica OAuth deve intercettare questo e attivare un flusso di riautenticazione per l'utente, non fallire silenziosamente. Il peggior risultato è un utente che pensa che le email vengano lette, ma il token è stato revocato per settimane. Crea un controllo esplicito dello stato dell'account e avvisa gli utenti quando è necessaria la riautenticazione.
OAuth Scopes: Cosa Richiedere (e Cosa Non Fare)
La minimizzazione degli ambiti è sia una best practice in termini di sicurezza che una strategia di ottimizzazione per il consenso. La richiesta di ambiti maggiori di quelli necessari induce gli utenti a esitare (o a rifiutare) nella schermata di consenso e innesca un maggiore controllo durante le revisioni di Google CASA e Microsoft Publisher.
| Ambito | Fornitore | Caso d'uso | Sensibilità | Recensione CASA? |
|---|---|---|---|---|
| gmail.solodlettura | Gmail | Leggi tutte le email e i metadati | Alto | Sì - Tier 2 |
| gmail.invia | Gmail | Inviare email come utente | Alto | Sì - Tier 2 |
| modifica gmail | Gmail | Leggere, inviare, eliminare, etichettare | Alto | Sì - Tier 2 |
| etichette gmail | Gmail | Leggi e gestisci solo etichette | Basso | No |
| Posta.Leggi | Prospettiva | Leggi tutta la posta | Medio | Verifica dell'editore |
| Mail.Send | Prospettiva | Invia email come utente | Medio | Verifica dell'editore |
| Mail.ReadWrite | Prospettiva | Leggi, invia, elimina, gestione cartella | Alto | Verifica dell'editore |
| accesso offline | Prospettiva | Ottieni token di aggiornamento | Basso | No |
| posta-r | IMAP (Yahoo) | Leggi email tramite IMAP/XOAUTH2 | Medio | Revisione dello sviluppatore Yahoo |
Token aggiornati e ruotati per te
Smetti di scrivere codice per il ciclo di vita dei token. Collega una casella di posta una sola volta, Unipile mantiene l'accesso attivo su tutti i provider.
Conformità: SOC2, GDPR, CASA
Un'API email OAuth che gestisce le caselle di posta degli utenti si trova all'incrocio tra sicurezza e conformità alla privacy. Ecco i quattro framework di cui la maggior parte degli acquirenti enterprise chiederà - e cosa significa il modello di token di OAuth per ciascuno di essi.
I revisori SOC2 esaminano la gestione dei token come parte dei criteri di Disponibilità e Riservatezza. I token OAuth devono essere crittografati a riposo (AES-256 o KMS), registrati in accesso e soggetti a una politica di rotazione formale. La memorizzazione dei token di aggiornamento in chiaro è una violazione automatica. L'utilizzo di un'API email OAuth ospitata come Unipile (certificata SOC2) sposta questa responsabilità.
Ai sensi del GDPR, la tua app è un elaboratore di dati quando accede al contenuto delle email degli utenti. Hai bisogno di un accordo sul trattamento dei dati (DPA) con il provider della tua infrastruttura API di email OAuth. La revocabilità di OAuth soddisfa direttamente l'articolo 17 (diritto alla cancellazione): quando un utente revoca, il tuo accesso termina immediatamente. Documenta la tua base giuridica per l'accesso ai dati delle email (tipicamente il consenso tramite il flusso OAuth).
Quando la tua app API e-mail OAuth di Gmail supera i 100 utenti con ambiti sensibili, Google blocca l'aggiunta di ulteriori utenti fino al superamento del livello 2 CASA. Ciò richiede un test di penetrazione da parte di un laboratorio autorizzato CASA, la compilazione di un questionario sulla sicurezza e l'invio a Google di un rapporto di valutazione formale. Tempistica: 8-16 settimane. Costo: 10.000-25.000 TP4T. Le app verificate ottengono il badge "Verificato da Google" sulla schermata di consenso.
OAuth Email API: Modelli di Prezzi e Costi
Le API dei provider "gratuiti" di Google e Microsoft nascondono costi reali significativi. Ecco un modello di costo realistico per l'implementazione di un'API di posta elettronica OAuth su larga scala, che copre il percorso diretto del provider rispetto alle API unificate.
Le API di Google e Microsoft sono tecnicamente gratuite a livello di chiamata API. Tuttavia: il piano CASA Tier 2 di Google ha un costo compreso tra 10.000 e 25.000 TP4T e richiede almeno 3 mesi di lavoro tecnico. La verifica degli editori per Microsoft richiede un account Partner Network e la verifica legale del dominio. Tempo di sviluppo necessario per realizzare 3 flussi, la gestione dei token e la gestione degli errori: 6-10 settimane. Manutenzione annuale: 2-4 settimane all'anno per ogni fornitore.
L'API email di OAuth di Unipile include la conformità di tutti i provider (CASA, Publisher Verification), la gestione dei token e un'API email unificata sotto un'unica sottoscrizione. Per i team che distribuiscono la connettività email come una funzionalità (non un prodotto), il calcolo del ROI è semplice: settimane di tempo di ingegneria risparmiate rispetto a un costo mensile dell'API. Vedi il confrontare fornitori di API per email Guida per una ripartizione completa dei costi.
Errori comuni nell'implementazione di OAuth per email
Questi sono gli errori più comuni che gli sviluppatori commettono quando creano un'API email OAuth per la prima volta, e cosa fare invece.
Google invalida i token di aggiornamento se l'utente non ha utilizzato la tua app per 6 mesi. La tua chiamata di aggiornamento del token restituisce concessione_non_valida. Correggere: implementare un "controllo di stato del token" periodico che effettui una chiamata leggera all'API di Gmail per ciascun account collegato almeno una volta ogni 30 giorni per impedire la scadenza dovuta all'inattività.
Richiesta modifica gmail quando hai solo bisogno gmail.solodlettura inflaziona la tua schermata di consenso e fa abbandonare agli utenti il flusso OAuth. Inoltre, aumenta il tuo requisito di livello CASA. Richiedi sempre l'ambito minimo necessario. Puoi richiedere ambiti aggiuntivi in modo incrementale in seguito.
Il limite di 100 utenti per l'ambito sensibile di Gmail è il blocco di crescita più comune per le implementazioni API di posta elettronica OAuth. Pianifica la revisione CASA prima di raggiungere 50 utenti: la revisione richiede 8-16 settimane e la crescita dei tuoi utenti sarà bloccata finché non sarà in sospeso.
La registrazione prolissa delle richieste che cattura le intestazioni di autorizzazione registrerà i tuoi token di accesso in testo normale. Implementa un middleware di scrubbing dei log che redaction Bearer [TOKEN] pattern prima che i log vengano scritti su qualsiasi archivio permanente.
Alcuni server di posta elettronica aziendali operano dietro configurazioni IMAP personalizzate che non supportano OAuth. La tua API di posta elettronica OAuth deve avere un percorso di fallback compatibile per i provider IMAP-only. Incorpora questo nel tuo flusso di connessione dell'account fin dal primo giorno, altrimenti escluderai una quota significativa di utenti B2B. Vedi la nostra Integrazione IMAP guida per il pattern di fallback completo.
Costruire invece di unire i provider
Ottieni un'integrazione email OAuth funzionante oggi stesso. Livello gratuito, nessuna carta di credito, gli ambiti completi di Gmail e Microsoft sono disponibili.
Domande frequenti
Le domande più comuni che gli sviluppatori pongono quando creano un'integrazione API di posta elettronica OAuth - risposte precise.
https://oauth2.googleapis.com/token, ambiti nel gmail.* namespace. Per Outlook (copre Outlook.com, Microsoft 365 e Exchange Online): Microsoft Identity Platform, endpoint token https://login.microsoftonline.com/common/oauth2/v2.0/token, ambiti sotto https://graph.microsoft.com/. Per IMAP: IMAP non è un provider OAuth. Utilizza credenziali nome utente/password o password per le app. XOAUTH2 è esistito come estensione SASL per un piccolo numero di provider ma è stato in gran parte deprecato.grant_type=refresh_token. Per Google: POST a https://oauth2.googleapis.com/token. Per Microsoft: POST su https://login.microsoftonline.com/common/oauth2/v2.0/token. Se ricevi concessione_non_valida, il token di aggiornamento è scaduto o è stato revocato - richiedi all'utente di autenticarsi nuovamente.gmail.solodlettura leggere, gmail.invia inviare, modifica gmail per lettura/scrittura/eliminazione completa. Per Outlook: Posta.Leggi leggere, Mail.Send inviare, Mail.ReadWrite per accesso completo - più accesso offline per ottenere token di aggiornamento. Richiedi sempre lo scope minimo necessario per il tuo caso d'uso. Vedi pagina API email per raccomandazioni di ambito specifiche per casi d'uso.etichette gmail (non soggetto al CASA), avviare il processo CASA prima di raggiungere 50 utenti (richiede 8-16 settimane), oppure utilizzare un'API di posta elettronica OAuth ospitata come Unipile la cui infrastruttura ha già superato la revisione CASA, eliminando questo requisito per la tua applicazione./api/v1/hosted/accounts/link. Passi una tipo (GOOGLE, MICROSOFT, o IMAP) e Unipile genera un URL di autenticazione ospitato. L'utente completa il consenso OAuth sull'infrastruttura di Unipile, che ha superato il controllo CASA di Google e la verifica dell'editore di Microsoft. Dopo il consenso, Unipile invia un webhook con il account_id. Tutta la gestione e il refresh dei token sono gestiti internamente.concessione_non_valida. La tua API OAuth email deve intercettare questo, contrassegnare l'account collegato come disconnesso e notificare all'utente un link di riautenticazione. Con Unipile, un webhook di revoca viene attivato automaticamente in modo che il tuo sistema venga notificato in tempo reale, senza necessità di polling.
IT 
EN 
FR 
ES 
DE 
BR 
NL 
PL 
TR