LinkedIn
Instagram
WhatsApp
Telegramma
Calendario di Google
Partecipare alla comunità SlackGoogle OAuth Verifica Credenziali API Gmail
Passaggio per passaggio: crea credenziali OAuth per Gmail API, supera la verifica dell'app Google e la revisione CASA di Livello 2 - o distribuisci oggi stesso con la chiave OAuth già certificata di Unipile e certifica la tua in seguito.
// Salta del tutto la configurazione di Google Cloud.La chiave OAuth certificata di Unipile se ne occupa. const response = await fetch('https://api.unipile.com/api/v1/hosted/accounts', { method: 'POST', intestazioni: { 'X-API-KEY': process.env.UNIPILE_API_KEY, 'Content-Type': 'application/json' }, body: JSON.stringify({ tipo: 'GOOGLE', nome 'utente-123', scadeil '2026-12-31' })}); const { url } = await risposta.json();-- Reindirizza il tuo utente a `url` - fatto.La verifica di Google OAuth è in realtà
La verifica di Google OAuth è il processo di approvazione formale attraverso il quale Google conferma che la tua applicazione gestisce i dati degli utenti in conformità con le sue norme. Finché la tua app non supera questa revisione, è considerata non verificata, il che significa che gli utenti visualizzano una schermata di avviso e sei limitato a un massimo di 100 utenti di test. La revisione è obbligatoria ogni volta che la tua app richiede ambiti API Gmail sensibili o ristretti da utenti esterni (non interni).
Ambiti sensibili: cosa sono
Gli ambiti sensibili consentono alla tua app di leggere o modificare dati utente oltre alle informazioni di base del profilo. Per Gmail, questi includono:
gmail.solodlettura- leggi tutti i messaggigmail.inviainviare email per conto dell'utentemodifica gmail- leggere, comporre, archiviaremail.google.com- accesso completo (limitato)
Gli ambiti sensibili richiedono una valutazione di sicurezza di Google. Gli ambiti limitati (come l'accesso IMAP completo) richiedono inoltre un audit CASA di livello 2. Vedere il riferimento completo degli ambiti nel nostro Guida agli scope di Gmail API.
Perché l'API di Gmail innesca sempre questo
A differenza di un flusso di accesso base di Google (che richiede solo dati del profilo), l'API Gmail richiede sempre ambiti che concedono l'accesso al contenuto della casella di posta di un utente. Google considera qualsiasi autorizzazione a livello di casella di posta come sensibile per definizione.
Ciò significa che ogni sviluppatore che desidera utilizzare l'API Gmail per utenti esterni deve passare attraverso la verifica dell'app OAuth di Google: non esiste una versione dell'API Gmail che aggiri questo requisito per l'uso in produzione.
Non siete sicuri se vi servono credenziali OAuth o una semplice chiave API? Leggete la nostra Chiave API di Gmail vs OAuth: Guida.
Distinzione chiave: La verifica OAuth di Google non è un evento unico. Se aggiungi nuovi ambiti a un'app già verificata, devi sottoporre l'app a una nuova revisione che copra tali ambiti aggiuntivi. Pianifica la tua strategia di ambiti prima di iniziare il processo: ti farà risparmiare settimane.
Settimane di verifica.
Utilizzo Chiave di Unipile e inizia adesso.
Non perdere clienti in attesa delle recensioni di Google. Collega gli account Gmail in 5 minuti con le nostre credenziali sviluppatore pre-verificate.
Come ottenere le credenziali API di Gmail: passaggio per passaggio
Ottenere le credenziali OAuth per Gmail richiede sei passaggi distinti nella Google Cloud Console. Ecco la sequenza completa: dalla creazione del tuo progetto fino all'ottenimento di un set funzionante. ID cliente e segreto del cliente.
- Creare un progetto Google Cloud - il tuo container isolato per fatturazione e API.
- Abilita l'API di Gmail - attiva l'API nella Libreria API per il tuo progetto.
- Configura la schermata di consenso OAuth - scegli il tipo di app (esterna vs interna), inserisci il nome dell'app, l'email di supporto e i domini autorizzati.
- Aggiungi ambiti - seleziona gli ambiti di Gmail necessari alla tua app; questo determina se è necessaria una revisione della sicurezza.
- Crea un ID client OAuth - scegli il tipo di applicazione (Web, Desktop o iOS/Android) e registra i tuoi URI di reindirizzamento.
- Invia per verifica - se la tua app è esterna e utilizza ambiti sensibili, invia tramite il portale di verifica di Google.
Vai a console.cloud.google.com, fai clic sul selettore di progetto nella barra di navigazione in alto e seleziona "Nuovo progetto". Assegna un nome che rifletta il tuo prodotto: verrà visualizzato nella schermata di consenso OAuth che gli utenti vedono.
Attiva la fatturazione per il progetto anche se prevedi di rimanere entro i limiti delle quote gratuite. Molte API (tra cui Gmail) richiedono l'associazione di un account di fatturazione prima di poter essere attivate, anche in caso di utilizzo $0.
Google Cloud Console: crea un nuovo progetto tramite il selettore di progetti nella barra di navigazione in alto.
Nella Google Cloud Console, vai su "API e servizi" > "Libreria". Cerca "Gmail API" e fai clic su "Attiva". Probabilmente vorrai anche attivare l'API Google People se hai bisogno di dati di contatto insieme alle email.
Dopo averla abilitata, l'API di Gmail apparirà nella tua dashboard "API abilitate". Le chiamate API senza credenziali valide restituiranno un 403 accessoNonConfigurato errore anche in questa fase - vengono dopo le credenziali.
Libreria API di Google: cerca "API Gmail" e fai clic su Abilita per attivarla per il tuo progetto.
Vai su "API e servizi" > "Schermata di consenso OAuth". Scegli il tuo tipo di utente:
- Interno - solo gli utenti della tua organizzazione Google Workspace. Non è richiesta alcuna verifica.
- Esterno - qualsiasi account Google. Verifica richiesta per ambiti sensibili/limitati oltre i 100 utenti di prova.
Schermata di consenso OAuth: scegli Utente interno (solo Workspace) o Utente esterno (qualsiasi account Google) come tipo di utente.
Inserisci il nome dell'app, l'indirizzo email di supporto utente e l'indirizzo email di contatto dello sviluppatore. Questi campi appaiono nella schermata di consenso che gli utenti vedono quando autorizzano la tua app. Aggiungi il tuo dominio autorizzato (il dominio della tua homepage e dell'URL dell'informativa sulla privacy).
Per una descrizione dettagliata di ogni campo, il limite di 100 utenti e la scelta tra Interno ed Esterno, consulta il nostro guida alla configurazione della schermata del consenso.
Informazioni sull'app: inserisci il nome dell'app, il logo e l'indirizzo email del supporto esattamente come devono apparire nella schermata di consenso.
Dominio dell'app: fornisci URL attivi per la tua home page, l'informativa sulla privacy e i termini di servizio. Il team di revisione di Google li controlla.
Domini Autorizzati: aggiungi il dominio principale della tua app. Solo gli URI di questo dominio possono essere utilizzati come URI di reindirizzamento.
Informazioni di contatto dello sviluppatore: Google utilizza questa email per notificarti le modifiche allo stato di verifica della tua app.
Suggerimento: La sezione "Dominio dell'app" accetta più collegamenti (Homepage, Informativa sulla privacy, Termini di servizio). Il team di verifica di Google verificherà che questi URL siano attivi e riflettano gli ambiti richiesti. Un URL dell'informativa sulla privacy mancante o non funzionante è uno dei motivi più comuni per cui le verifiche vengono rifiutate.
Nella configurazione della schermata di consenso, fai clic su "Aggiungi o rimuovi ambiti". Utilizza il filtro per trovare gli ambiti di Gmail. L'ambito che scegli ha un impatto diretto sul tuo percorso di verifica:
gmail.inviaogmail.solodlettura- sensibile, richiede valutazione di sicurezza.modifica gmailomail.google.com- ristretto, richiede CASA di livello 2 in aggiunta.openid email profilosolo - nessuna verifica necessaria (accesso base).
Aggiungi o rimuovi ambiti: seleziona gli ambiti di Gmail richiesti dalla tua app. La selezione degli ambiti determina direttamente il tuo percorso di verifica.
Pianifica attentamente la selezione dell'ambito. Aggiungere un ambito ristretto in seguito significa dover inviare nuovamente l'intera app per un'ulteriore revisione CASA Tier 2. Per il riferimento completo dell'ambito e quali API ciascun ambito sblocca, consulta il nostro Guida agli scope di Gmail API.
Vai su "API e servizi" > "Credenziali" > "Crea credenziali" > "ID client OAuth". Seleziona il tipo di applicazione:
- Applicazione web - per le app lato server. Registra i tuoi URI di reindirizzamento (ad esempio.
https://yourapp.com/oauth/callback). - App desktop - per le applicazioni installate. Usa il reindirizzamento di loopback.
- iOS / Android - app mobili, utilizza schemi URI personalizzati.
Pannello Credenziali: seleziona "ID client OAuth" per generare il client_id e il client_secret necessari alla tua app.
Dopo la creazione, scarica il file delle credenziali JSON. Contiene le tue ID cliente, segreto del cliente, e URI di reindirizzamento registrati. Memorizzalo in modo sicuro: non inviarlo mai al controllo di origine.
Per un approfondimento sulla differenza tra questo tipo di credenziale e una semplice chiave API, consulta il nostro Chiave API di Gmail vs credenziali OAuth: guida.
Token di accesso e token di aggiornamento: quando un utente completa il flusso OAuth, ricevi un breve token_accesso (valido per ~1 ora) e un token_di_aggiornamento (di lunga durata, memorizzato lato server). Il tuo server usa il token di aggiornamento per ottenere nuovi token di accesso senza richiedere nuovamente all'utente. Richiedi sempre access_type=offline e consenso alla prima autorizzazione per ricevere il token di aggiornamento. Memorizza i token di aggiornamento crittografati a riposo.
Per una panoramica più ampia su come OAuth si inserisce nell'architettura delle API per e-mail, comprese le strategie di sincronizzazione e le differenze tra i provider, consulta il nostro Guida API OAuth per email.
Usa la chiave UnipileL'avviso "Questa app non è verificata", il limite di 100 utenti e le esenzioni
Prima che la tua app superi la verifica dell'app OAuth di Google, ogni utente che tenta di autorizzarla visualizzerà una schermata di avviso. Google applica anche un limite massimo di 100 utenti per le app esterne non verificate. Ecco cosa significa esattamente e quando non si applica.
Lo schermo dice: "Questa app non è verificata. Questa app non è stata verificata da Google. Potrebbe richiedere l'accesso a informazioni sensibili. Scopri i rischi." Gli utenti devono fare clic su "Avanzate" e quindi su "Vai a [Nome App] (non sicuro)" per procedere. La maggior parte degli utenti non tecnici si fermerà qui: questo è il vero costo del saltare o ritardare la verifica.
Quando la verifica delle app di Google OAuth NON è richiesta
Solo per uso interno
Se imposti la tua schermata di consenso OAuth su "Interno" e la tua app serve solo utenti all'interno della tua organizzazione Google Workspace, non è richiesta alcuna verifica, indipendentemente dagli ambiti richiesti. Questo è il percorso più rapido per gli strumenti interni.
Modalità di test (meno di 100 utenti)
Un'app esterna non verificata può avere fino a 100 utenti di prova aggiunti tramite la Google Cloud Console. Quegli utenti specifici possono autorizzare l'app senza visualizzare un blocco rigido: vedono l'avviso ma possono procedere. Utile per lo sviluppo e la beta privata con un piccolo team.
Ombreggiature di base
Se la tua app richiede solo ambiti non sensibili (openid, email, profile - accesso base tramite Google), non è necessaria alcuna verifica anche per utenti esterni di qualsiasi entità. La verifica viene attivata specificamente da ambiti sensibili e con limitazioni.
Inquadratura importante: L'intento del limite di 100 utenti e della schermata di avviso è proteggere gli utenti mentre un'app è in fase di revisione. La risposta corretta al raggiungimento del limite è inviare la tua app per la verifica dell'app Google OAuth, non creare più progetti Google Cloud per distribuire gli utenti tra di essi. Google proibisce esplicitamente questo approccio e può comportare la sospensione del tuo account sviluppatore. Il percorso conforme consiste nel verificare la tua app o nell'utilizzare una piattaforma che fornisce già una chiave OAuth verificata, come Unipile.
Verifica dell'app Google: tempistiche e costi nel 2026
La verifica delle app di Google non è un processo unico: ha tre percorsi distinti a seconda degli ambiti richiesti dalla tua app. Ogni percorso ha la sua tempistica e i suoi costi. Ecco cosa aspettarsi nel 2026.
Se la tua app utilizza solo ambiti non sensibili (accesso base con Google), Google potrebbe comunque richiedere la verifica del marchio per confermare l'identità della tua app e il dominio della sua home page. Questo è tipicamente un processo di 2-3 giorni lavorativi senza costi aggiuntivi oltre al tuo tempo.
Dovrai verificare la proprietà del dominio tramite la Google Search Console e assicurarti che la schermata di consenso OAuth descriva accuratamente la tua app.
Le app che richiedono ambiti Gmail sensibili devono sottoporsi alla valutazione completa della sicurezza di Google. Il team di Google esamina le pratiche di gestione dei dati della tua app, l'informativa sulla privacy e la giustificazione per ogni ambito richiesto.
Il tempo di consegna tipico è 2-4 settimane quando la tua presentazione sarà completa. Le presentazioni incomplete (mancanza di informativa sulla privacy, giustificazioni vaghe dello scopo, domini autorizzati non corrispondenti) faranno ripartire il contatore. Google potrebbe richiedere una demo o documentazione aggiuntiva durante questo periodo.
App che richiedono ambiti ristretti - principalmente https://mail.google.com/ (accesso completo a livello IMAP) - deve completare un Valutazione di sicurezza CASA di livello 2 Oltre alla revisione di Google. CASA (Cloud Application Security Assessment) è una revisione indipendente della sicurezza condotta da un laboratorio approvato da Google.
Nel 2026 Google offrirà un percorso self-service CASA Tier 2 tramite laboratori approvati, tipicamente con un costo di $540-$1.000 (costi di laboratorio per la scansione automatizzata). Questo rappresenta un miglioramento significativo rispetto al sistema legacy. La precedente valutazione della sicurezza, gestita manualmente da Google per la stessa classe di ambito, comportava costi da 15.000 a 75.000 e sono occorsi mesi - quel tracciato legacy si applica ancora ad alcune app grandfathered e a casi limite aziendali. Nella definizione del budget, conferma con il tuo laboratorio prescelto quale tracciato si applica alla tua app.
Tempistica totale inclusa la revisione di Google dopo CASA: 4-12 settimane dalla prima presentazione all'approvazione.
Riepilogo costi: verifica dell'app Google OAuth nel 2026
| Traccia di verifica | Livello di ambito | Cronologia | Costo |
|---|---|---|---|
| Verifica del marchio | Non sensibile (openid, email, profile) | 2-3 giorni lavorativi | Gratuito |
| Valutazione della sicurezza | Sensibile (gmail.send, gmail.readonly, gmail.modify) | 2-4 settimane | Gratuito |
| CASA Livello 2 (self-service, 2026) | Restricted (mail.google.com) | 4-8 settimane | ~$540-$1.000 |
| CASA Livello 2 (manuale legacy, pre-2025) | Restricted (mail.google.com) | 8-12 settimane | $15k-$75k |
Fonti: Politiche di Google OAuth 2.0 (developers.google.com) e Google Cloud - Panoramica della verifica delle app OAuth (support.google.com). I prezzi del servizio self-service CASA Tier 2 si basano sulle tariffe di laboratorio approvate a partire dal primo trimestre del 2026 e possono variare a seconda del laboratorio e del numero di app incluse. Il percorso tradizionale $15k-$75k si applicava alle app che avevano superato il precedente programma obbligatorio di valutazione della sicurezza di Google prima che fosse disponibile l'opzione self-service CASA.
Salta l'attesaErrori comuni di Google OAuth in cui potresti incorrere
Quando gestisci il tuo progetto Google Cloud, una manciata di errori si presenta ripetutamente durante lo sviluppo e dopo la messa in produzione. Ecco un riferimento rapido per i sei più comuni.
L'URI di reindirizzamento nella tua richiesta non corrisponde esattamente a uno registrato nella Google Cloud Console (protocollo, barra finale e porta hanno tutti importanza).
L'amministratore di Google Workspace dell'utente ha bloccato le app OAuth di terze parti o ha limitato gli ambiti specifici richiesti dalla tua app.
La tua app utilizza ambiti sensibili o limitati ma non ha completato il processo di verifica di Google, pertanto Google blocca il consenso per i nuovi utenti.
Il token di aggiornamento è scaduto o è stato revocato (l'utente ha modificato la password, ha revocato l'accesso o il token è rimasto inattivo per 6 mesi). L'utente deve eseguire nuovamente l'autenticazione.
La schermata di consenso è configurata erroneamente nella Google Cloud Console: tipo di utente errato (interno vs esterno), utenti di test mancanti o l'app è ancora in stato di bozza.
Una stringa di ambito contiene un errore di battitura, oppure l'API corrispondente (ad es. Gmail API) non è stata abilitata nella Google Cloud Console per il tuo progetto.
Hai bisogno della diagnosi completa? Ognuno di questi errori ha una correzione specifica. Consulta la nostra guida completa per Errori comuni di Google OAuth e Gmail API e come risolverli.
Quando OAuth è gestito da Unipile, un intermediario tecnico indipendente che agisce per conto di ciascun utente autenticato, questi errori vengono gestiti a livello di API. Unipile è già certificato CASA Tier 2, quindi gli ostacoli di verifica vengono gestiti una sola volta, non una volta per progetto.
Settimane di verifica.
Utilizzo Chiave di Unipile e inizia adesso.
Non perdere clienti in attesa delle recensioni di Google. Collega gli account Gmail in 5 minuti con le nostre credenziali sviluppatore pre-verificate.
Google OAuth, Semplificato: Fai da te vs. gestito - spedire ora o aspettare settimane?
Se la tua app necessita l'accesso a Gmail per utenti esterni, hai due opzioni: gestire il tuo progetto Google Cloud attraverso il processo completo di verifica dell'app OAuth di Google (6-12 settimane), oppure costruire su una piattaforma che possiede già una chiave OAuth certificata CASA Tier 2 (1-2 giorni). Ecco come si presenta ciascuna opzione, e perché non si escludono a vicenda.
La lettura strategica: Il percorso fai-da-te ha senso a lungo termine se desideri la piena proprietà del tuo brand OAuth e della schermata di consenso. Il percorso gestito (Unipile) ha senso quando devi rilasciare subito, evitare il limite di 100 utenti o ritardare il costo CASA Tier 2. Questi percorsi non si escludono a vicenda: puoi costruire su Unipile oggi e gestire la tua certificazione in parallelo, quindi passare alle tue credenziali (Bring Your Own Credentials) una volta che la tua app è verificata.
Se il tuo caso d'uso è limitato a Workspace (strumenti interni, automazione HR, nessuna approvazione per utente), l'alternativa server-to-server è un account di servizio con delega a livello di dominio, consulta il nostro Account di servizio Gmail e guida DWD.
Nota sulla conformità: Unipile è un intermediario tecnico indipendente, non affiliato, approvato o sponsorizzato da Google. Il client OAuth Google di Unipile è certificato CASA Tier 2, consentendo ai tuoi utenti di autorizzare l'accesso a Gmail senza visualizzare l'avviso "app non verificata". Questo non è un workaround per la revisione di sicurezza di Google: la revisione si applica comunque se costruisci la tua app Google Cloud; Unipile l'ha già superata per le connessioni che intermedia per tuo conto. Gli utenti possono revocare l'accesso in qualsiasi momento tramite la pagina delle autorizzazioni del proprio Account Google.
Provalo subito su Unipile chiave certificata, certificare in parallelo, cambiare quando si è pronti
Non devi scegliere tra spedire velocemente e possedere le tue credenziali Google. Unipile agisce come un intermediario tecnico indipendente: il suo client Google OAuth è già certificato CASA Tier 2, quindi i tuoi utenti non vedranno mai l'avviso di app non verificata e non ci sarà un limite di 100 utenti. Esegui la verifica della tua app Google in parallelo, quindi passa alle tue credenziali (Bring Your Own Credentials) in qualsiasi momento. Ecco il percorso in 3 fasi.
Test sulla chiave certificata - spedizione in pochi minuti
Crea un account Unipile gratuito e genera una chiave API. Utilizza l'endpoint di autenticazione ospitato per generare un URL a collegamento singolo per ciascun utente. Reindirizza l'utente a quell'URL: la schermata di consenso OAuth di Google di Unipile (già certificata CASA Tier 2) gestisce l'autorizzazione. L'utente non vedrà mai un avviso relativo a un'"app non verificata".
Quando l'autorizzazione viene completata, Unipile invia un webhook al tuo server con l'ID dell'account collegato. Da quel momento in poi la tua app potrà leggere, inviare e sincronizzare Gmail tramite l'API unificata di Unipile. senza creare un singolo progetto Google Cloud.
// Passaggio 1: genera un URL di autenticazione a singolo link per il tuo utente
const res = await fetch('https://api.unipile.com/api/v1/hosted/accounts', {
method: 'POST',
intestazioni: {
'X-API-KEY': process.env.UNIPILE_API_KEY,
'Content-Type': 'application/json'
},
body: JSON.stringify({
tipo: 'GOOGLE',
nome 'utente-456', // il tuo ID utente interno
scadeil '2027-01-01',
notify_url: 'https://yourapp.com/webhooks/unipile'
})
});
const { url } = await res.json();
// Reindirizza l'utente a `url` - lo schermo di consenso certificato di Unipile gestisce il resto.Esegui la tua verifica Google OAuth in parallelo
Mentre il tuo prodotto è attivo e gli utenti sono attivi, avvia la configurazione del tuo progetto Google Cloud e invia la tua app per la verifica dell'app Google OAuth. Segui la configurazione delle credenziali in 5 passaggi sopra. Se la tua app utilizza ambiti ristretti, avvia la tua valutazione self-service di livello 2 CASA tramite un laboratorio approvato da Google.
C'è nessuna fretta in questo passaggio mentre sei sulla chiave certificata di Unipile: i tuoi utenti non sono bloccati, non vedono alcun avviso e non c'è alcun limite di utenti. Esegui il processo al ritmo che si adatta al tuo team: tipicamente 2-4 settimane per ambiti sensibili, 4-12 settimane se è necessario il CASA di Livello 2.
Per la guida alla selezione dello scope, consulta il nostro Guida agli scope di Gmail API - scegliere ambiti minimi può spostarti dal percorso ristretto (richiesto da CASA) al percorso sensibile (revisione libera), risparmiando tempo e costi.
Passa alle tue credenziali (BYOC) - una modifica di configurazione
Una volta verificata la tua app Google Cloud e che hai la tua ID cliente e segreto del cliente, configura Unipile per utilizzare le tue credenziali OAuth per le nuove connessioni account. Questo è il modello Bring Your Own Credentials (BYOC): Unipile continua ad agire come un intermediario tecnico indipendente elaborazione delle richieste per conto di ciascun utente autenticato, utilizzando ora le tue credenziali verificate invece della chiave condivisa.
Gli account già collegati rimangono attivi. Il cambiamento riguarda solo le nuove autorizzazioni. I tuoi utenti vedranno il nome verificato della tua app nella schermata di consenso, che sostituirà quella con il marchio Unipile. Hai scelto tu quando investire nella verifica: non il primo giorno, quando dovevi lanciare il prodotto.
Microsoft è diversa: perché Azure non necessita di una revisione in stile CASA
Se la tua applicazione deve accedere sia a Gmail che a Outlook, l'onere della verifica è asimmetrico. La verifica delle app di Google OAuth, inclusa una potenziale revisione di livello 2 CASA, si applica solo a Google. L'approccio di Microsoft Azure alla registrazione delle app e al consenso OAuth è architettonicamente diverso e non richiede un'audit di sicurezza esterna equivalente.
Qualsiasi app che richieda ambiti Gmail sensibili o limitati da utenti esterni deve superare la valutazione di sicurezza di Google. Gli ambiti limitati richiedono inoltre il livello 2 di CASA.
- Avviso relativo alle app non verificate mostrato agli utenti
- Massimo di 100 utenti fino alla verifica
- È richiesto CASA Tier 2 per ambiti limitati (~$540-$1k self-service)
- È necessaria una nuova revisione quando si aggiungono nuovi ambiti sensibili
- Tempistica: da 2 a 12+ settimane a seconda del livello di complessità
Azure Active Directory (ora Microsoft Entra ID) utilizza un modello di consenso amministrativo per gli ambiti con privilegi elevati. Non è previsto alcun requisito di audit esterno in stile CASA per gli ambiti di accesso alla posta standard.
- Nessun avviso di app non verificata per flussi standard
- Nessun limite di utenti durante lo sviluppo
- Nessuna revisione esterna della sicurezza obbligatoria
- Consenso dell'amministratore richiesto per le autorizzazioni a livello di tenant negli ambienti tenant aziendali
- Microsoft 365 copre sia Outlook personale che Exchange Online aziendale tramite lo stesso flusso OAuth
Implicazione pratica per app multi-provider: se stai creando un prodotto che legge le email sia dagli account Gmail che Outlook, la tempistica di verifica della tua app Google OAuth governa la data di lancio, non quella di Microsoft. Questo è uno degli argomenti più forti a favore dell'utilizzo dell'API unificata di Unipile: entrambi i provider vengono gestiti tramite un'unica integrazione e la chiave certificata di Unipile copre il requisito di Livello 2 CASA di Google pronto all'uso, rimuovendolo interamente dal tuo percorso critico.
Per un approfondimento sul lato Microsoft di questo argomento - inclusi la registrazione delle app Azure, i flussi di consenso e l'accesso all'API Microsoft Graph - vedi il nostro Guida OAuth di Microsoft Graph.
Come Unipile gestisce i tuoi dati
Unipile è un intermediario tecnico indipendente. Le tre note seguenti spiegano nel dettaglio come fluiscono i dati, cosa archivia Unipile e quali sono le tue responsabilità come cliente, nel contesto dell'accesso a Google OAuth e Gmail API.
Cosa memorizza Unipile e cosa no
Unipile non mantiene un archivio parallelo o una copia indipendente dei dati Gmail dei tuoi utenti. Quando la tua applicazione richiede dati email tramite l'API Unipile, Unipile li recupera dai server di Google per conto dell'utente autenticato e la restituisce alla tua applicazione. I dati sono limitati rigorosamente alla sessione dell'utente autenticato e alle autorizzazioni concesse durante il flusso OAuth. Unipile non conserva il contenuto dei messaggi oltre quanto necessario per soddisfare la risposta dell'API.
Intermediario tecnico indipendente - non partner di Google
Unipile opera come un intermediario tecnico indipendente, agendo per conto di ciascun utente autenticato che ha concesso l'accesso tramite la schermata di consenso di OAuth. Unipile è non affiliato, approvato o sponsorizzato da Google. Unipile non condivide le credenziali tra utenti: ogni account collegato utilizza i propri token OAuth, limitati all'autorizzazione di quell'utente. La tua applicazione accede ai dati di Gmail solo per gli utenti che hanno completato esplicitamente il flusso OAuth e concesso le autorizzazioni richieste.
I limiti di frequenza di Google si applicano - le decisioni di utilizzo sono tue
Unipile ritrasmette i limiti di frequenza e di quota dell'API Gmail di Google alla tua applicazione. L'API Gmail applica quote per utente (ad esempio, 250 unità di quota al secondo per utente, 1.000.000.000 unità di quota al giorno per progetto). Unipile espone questi limiti ma non li sovrascrive. Le decisioni sulla cadenza delle richieste, sul volume dei dati e sullo scopo del consenso dell'utente rimangono una decisione lato cliente. Sei responsabile di garantire che l'uso dei dati di Gmail da parte della tua applicazione sia conforme ai Termini di servizio dell'API di Google e alle aspettative dei tuoi utenti, come indicato nella tua informativa sulla privacy.
Per una panoramica completa delle funzionalità delle API di posta elettronica, tra cui invio, lettura e sincronizzazione tra Gmail, Outlook e IMAP, consulta il nostro Guida all'API Email.
Costruire con UnipileGoogle OAuth per sviluppatori FAQ
Risposte alle domande più comuni sulla verifica delle app Google OAuth, sulle credenziali API di Gmail e sull'OAuth gestito tramite Unipile.
La tua app necessita della verifica dell'app Google OAuth se è impostata su Esterno tipo di utente nella schermata di consenso OAuth e richiede ambiti Gmail sensibili o con limitazioni a utenti esterni alla propria organizzazione Google Workspace. Se la tua app richiede solo ambiti di base (openid, e-mail, profilo) o è impostato su Interno, non è richiesta alcuna verifica. Qualsiasi ambito che concede l'accesso alla cassetta postale di un utente, come gmail.solodlettura, gmail.invia, modifica gmail, o mail.google.com, è sensibile o riservata e innesca il requisito.
La timeline dipende dal livello di ambito utilizzato dalla tua app. Verifica del marchio (ambiti non sensibili): 2-3 giorni lavorativi. Revisione del campo sensibile (gmail.invia, gmail.solodlettura, modifica gmailtipicamente 2-4 settimane una volta completata la tua richiesta. CASA Livello 2 + ambiti sensibili/ristretti (mail.google.com): 4-12+ settimane totali. Incomplete submissions, such as missing privacy policy, vague scope justifications, or mismatched authorized domains, restart the clock.
La valutazione della sicurezza di Google stessa (per ambiti sensibili come gmail.invia e gmail.solodlettura) è libero. La verifica del brand è anch'essa gratuita. Se la tua app utilizza ambiti riservati (mail.google.com, è necessario un audit CASA Tier 2 da parte di un laboratorio approvato da Google. Il percorso self-service CASA Tier 2 per il 2026 costa circa da $540 a $1.000 nelle tasse di laboratorio. La precedente valutazione manuale richiesta per lo stesso ambito di classe aveva un costo da $15.000 a $75.000 e quella "legacy track" si applica ancora in alcuni casi limite e per le app "grandfathered".
Non è possibile saltare la verifica dell'app Google per un'app di produzione che serve utenti esterni con ambiti Gmail sensibili. Il limite di 100 utenti e l'avviso di app non verificata si applicano fino a quando l'app non verrà verificata. Le alternative conformi sono: impostare l'app su Interno (se serve solo agli utenti del tuo Workspace), usa Chiave OAuth certificata CASA Tier 2 di Unipile mentre la tua verifica viene eseguita in parallelo, o richiedi solo ambiti non sensibili che non attivano la verifica. La creazione di più progetti cloud per distribuire gli utenti tra di essi è vietata dalle policy di Google e può comportare la sospensione dell'account.
Vedi Endpoint API Gmail gestito da Unipile.L'avviso "App non verificata" dell'API Gmail viene visualizzato quando la schermata di consenso OAuth è impostata su "Esterno" e l'app richiede ambiti Gmail sensibili o riservati, ma non ha ancora completato il processo di verifica di Google. Viene mostrato a tutti gli utenti esterni alla tua lista di 100 utenti di test. Per risolverlo: invia la tua app per Verifica dell'app Google OAuth tramite la Google Cloud Console, o costruire sulla chiave OAuth pre-verificata e certificata CASA Tier 2 di Unipile. Gli utenti che si connettono tramite il flusso di autenticazione ospitato da Unipile non vedranno mai questo avviso.
CASA Livello 2 (Valutazione della sicurezza delle applicazioni cloud) è un audit di sicurezza indipendente richiesto da Google per le app che richiedono ambiti ristretti, principalmente https://mail.google.com/, che garantisce l'accesso completo a Gmail a livello IMAP. Viene condotto da un laboratorio approvato da Google. Nel 2026 sarà disponibile un percorso self-service a circa da $540 a $1.000. Avete bisogno del CASA Tier 2 solo se la vostra app richiede il mail.google.com scopo da utenti esterni. Se si utilizzano solo ambiti sensibili (gmail.invia, gmail.solodlettura, modifica gmail, CASA Tier 2 non è richiesto. Si applica invece la valutazione di sicurezza gratuita standard di Google.
A Chiave API di Gmail è per richieste pubbliche, non specifiche dell'utente e non consente l'accesso alla casella di posta di alcun utente. Credenziali OAuth per API di Gmail (ID cliente + segreto del cliente) vengono utilizzate per ottenere l'autorizzazione per utente ad accedere ai loro dati Gmail per loro conto. Per qualsiasi funzionalità che legga, invii o modifichi le email di un utente, sono necessarie credenziali OAuth, non una chiave API. Per un confronto dettagliato, consulta la nostra Chiave API di Gmail vs OAuth: Guida.
Hai ancora domande sulla verifica delle app Google OAuth o su OAuth di Gmail gestito? Il nostro team è qui per aiutarti.
Parlare con un esperto
IT 
EN 
FR 
ES 
DE 
BR 
NL 
PL 
TR