Errori comuni di Google OAuth e API di Gmail (e come risolverli uno per uno)

Guida OAuth di Google

Errori comuni di Google OAuth e API di Gmail (e come risolverli uno per uno)

Ogni sviluppatore che integra Gmail o Google Calendar con Google OAuth incontrerà almeno uno di questi errori di Google OAuth. Questa guida consolida tutti i 7 errori comuni di Google OAuth in un unico posto, con la causa esatta e la soluzione passo dopo passo per ciascuno. La comprensione di questi errori di Google OAuth ti farà risparmiare ore di debug.

oauth_callback.py
# Scambio di token OAuth di Google import richieste token_risposta = richieste.post( "https://oauth2.googleapis.com/token", dati={ "codice"codice_autorizzazione, "client_id": ID_CLIENTE, "client_secret"SEGRETO_CLIENT, "uri_di_reindirizzamento": URI_DI_REDIRECIONAMENTO, "grant_type": "codice_autorizzazione" } )
errore: redirect_uri_mismatch
redirect_uri_mismatch concessione_non_valida admin_policy_enforced accesso_negato ambito_non_valido
Riferimento rapido

Riferimento rapido: ogni errore di Google OAuth a colpo d'occhio

Una tabella riassuntiva di tutti i 7 errori di Google OAuth trattati in questa guida: fase in cui si verifica, causa principale e link alla correzione rapida nella sezione dettagliata sottostante. Segna questa tabella come riferimento quando esegui il debug degli errori di Google OAuth in fase di sviluppo o produzione.

Messaggio di errore Palcoscenico Causa principale Riparazione veloce
redirect_uri_mismatch Authorization L'URI di reindirizzamento nella tua richiesta non corrisponde esattamente a uno registrato nella Google Cloud Console Riparalo
admin_policy_enforced Authorization Un super amministratore di Workspace ha limitato le app OAuth o gli ambiti a cui gli utenti dell'organizzazione possono concedere l'accesso. Riparalo
accesso_negato Authorization L'app è in modalità di test e l'utente non è un utente di test, o l'app richiede ambiti ristretti senza verifica Riparalo
concessione_non_valida Aggiornamento del gettone Token di aggiornamento scaduto, revocato o utilizzato più di una volta (codice di autenticazione a uso singolo) Riparalo
Schermata di consenso mancante Console Google Cloud La nuova interfaccia di Google Cloud ha spostato la schermata di consenso OAuth; richiede inoltre il ruolo di Proprietario/Editor sul progetto Riparalo
ambito_non_valido Authorization Errore nell'URL dello scope o l'API di Google corrispondente non è abilitata nel progetto Riparalo
Google non ha verificato Authorization L'app utilizza ambiti sensibili/restretti ma non ha completato la verifica di Google; la modalità di test è limitata a 100 utenti Riparalo
redirect_uri_mismatch Authorization
Causa principaleL'URI di reindirizzamento nella richiesta non corrisponde esattamente a un URI registrato nella Google Cloud Console
admin_policy_enforced Authorization
Causa principaleL'amministratore principale di Workspace ha bloccato l'app o l'ambito per l'organizzazione
accesso_negato Authorization
Causa principaleApp in modalità di test, utente non aggiunto come utente di test, o ambiti con restrizioni senza verifica
concessione_non_valida Aggiornamento del gettone
Causa principaleToken di aggiornamento scaduto (6 mesi di inattività), revocato o codice di autenticazione monouso riutilizzato
Schermata di consenso mancante Console Google Cloud
Causa principaleLa nuova interfaccia utente di Google Cloud ha spostato la schermata di consenso OAuth in "Panoramica OAuth"
ambito_non_valido Authorization
Causa principaleErrore URL di ambito o API non abilitata nel progetto
Google non ha verificato Authorization
Causa principaleAmbiti sensibili/con restrizioni senza verifica; Modalità di test con limite di 100 utenti
Errore 400

Errore 400: redirect_uri_mismatch

Questo è l'errore OAuth di Google più comune per gli sviluppatori che configurano una nuova integrazione. Si verifica durante il passaggio di autorizzazione, prima che venga emesso alcun token.

Il messaggio di errore esatto

Errore 400: redirect_uri_mismatch L'URI di reindirizzamento nella richiesta non corrispondeva a un URI di reindirizzamento registrato. error=redirect_uri_mismatch

Causa

Causa principale

Google confronta il uri_di_reindirizzamento parametro che passi nell'URL di autorizzazione con l'elenco degli URI di reindirizzamento autorizzati registrati nel tuo client OAuth nella Google Cloud Console. Anche una singola differenza di carattere, una barra finale, http vs https, o una porta diversa - innesca questo errore.

Correggere (passo dopo passo)

Passaggi per risolvere
1 Aperto Console Google Cloud - API e Servizi - Credenziali.
2 Fai clic sul tuo ID client OAuth 2.0 per modificarlo.
3 Sotto URI di reindirizzamento autorizzati, aggiungi l'URI esatto che stai passando nel tuo codice - ad esempio. https://yourapp.com/oauth/callback. Il valore deve essere identico carattere per carattere, inclusi schema, porta, e slash finale.
4 Fare clic Risparmiare. Le modifiche potrebbero richiedere alcuni minuti per propagarsi.
5 Nel tuo codice, assicurati che uri_di_reindirizzamento il valore che passi all'endpoint di autorizzazione e all'endpoint di scambio del token sono identici.

redirect_uri_mismatch su localhost

Durante lo sviluppo locale, registra l'URI esatto di localhost che utilizzi - ad esempio http://localhost:3000/callback. Google consente http:// (non solo https://) per le URI di localhost. Se modifichi la porta di sviluppo, ricordati di aggiornare l'URI registrata.

Compreso: Origini JavaScript autorizzate vs URI di reindirizzamento

Questi sono due campi separati e servono scopi diversi. Le origini JavaScript autorizzate vengono utilizzate per i flussi OAuth lato browser (flusso implicito, Google Identity Services). Gli URI di reindirizzamento autorizzati vengono utilizzati per i flussi di codice di autorizzazione lato server. Aggiungere un URI alle origini JavaScript NON risolverà un redirect_uri_mismatch errore - devi aggiungerlo al campo URI di reindirizzamento. Un client OAuth di Google può avere fino a 100 URI di reindirizzamento registrati.

Errore 400 / Amministratore

Errore 400: policy_admin_imposta

Questo errore non è un bug nel tuo codice. È una politica organizzativa imposta da un super amministratore di Google Workspace. Uno sviluppatore normale non può risolverlo da solo.

Il messaggio di errore esatto

Errore 400: admin_policy_enforced L'account Google non può essere utilizzato per l'autorizzazione a causa delle policy della tua organizzazione. Contatta il tuo amministratore per maggiori informazioni. error=admin_policy_enforced

Causa

Causa principale

Un super amministratore di Google Workspace ha limitato quali applicazioni di terze parti o ambiti OAuth gli utenti dell'organizzazione possono concedere l'accesso. Questa configurazione avviene tramite Controlli API nella Google Admin Console. Quando un'app non è nell'elenco delle app approvate, ogni utente di Workspace riceverà questo errore quando tenterà di autorizzarla, indipendentemente dallo stato di verifica dell'app.

Questo è un controllo di conformità e sicurezza, non un'errata configurazione lato sviluppatore. La risoluzione corretta è sempre lato amministratore.

Correzione (solo lato amministratore)

Passaggi per il super amministratore
1 Accedi a Console di amministrazione Google a admin.google.com con un account di super amministratore.
2 Naviga verso Sicurezza - Controllo accessi e dati - Controlli API.
3 Fare clic Gestisci l'accesso delle app di terze parti.
4 Cerca l'app tramite il suo ID client OAuth o il nome dell'applicazione. Fai clic su di essa.
5 Cambia lo stato di accesso dell'app da Bloccato o Limitato a Affidabile. Ciò consente all'app di richiedere gli ambiti dichiarati.
6 Fare clic Cambiare Per confermare. Gli utenti dell'organizzazione possono ora autorizzare l'app.
Nota: gli utenti normali non possono risolvere questo problema

Un utente che incontra admin_policy_enforced non possono risolverlo da soli. Devono contattare il proprio super amministratore di Google Workspace e richiedere che la specifica app OAuth venga contrassegnata come "Trusted" (Fidato). Se l'utente è l'amministratore, può seguire i passaggi sopra indicati. Se il dominio applica una rigida policy "Consenti app specifiche", l'app deve prima essere aggiunta esplicitamente all'elenco delle approvate prima di poter essere impostata come "Trusted" (Fidato).

Se stai realizzando strumenti interni e vuoi evitare del tutto il consenso OAuth per utente, un account di servizio con delega a livello di dominio è l'alternativa - vedi la nostra Account di servizio Gmail e guida DWD.

accesso_negato

access_denied & "Questa app è bloccata" (app non verificata)

Gli utenti vedono una schermata "Questa app è bloccata" o ricevono accesso_negato nella callback OAuth. Questa presenta molteplici cause principali a seconda che la tua app sia ancora in modalità Test o stia richiedendo ambiti ristretti.

Il messaggio di errore esatto

Accesso bloccato: [Nome della tua app] non ha completato il processo di verifica di Google errore=access_denied -- oppure -- Questa app è bloccata. Questa app ha tentato di accedere a informazioni sensibili nel tuo Account Google. Contatta lo sviluppatore per maggiori informazioni.

Cause

App in modalità di test + utente non utente di test

Mentre la tua app OAuth è nello stato "In prova", solo gli utenti aggiunti esplicitamente come utenti di test possono autorizzarla. Chiunque altro riceve immediatamente un "accesso negato".

Modalità di test: raggiunto il limite di 100 utenti

La modalità di test è limitata a 100 utenti di test unici in qualsiasi momento. Una volta raggiunto il limite di 100, i nuovi utenti non potranno autorizzare l'app anche se aggiunti.

Ambiti sensibili o ristretti senza verifica

Ambiti come modifica gmail o gmail.invia sono Ambienti sensibili. Le app che li richiedono devono completare il processo di verifica dell'app di Google prima che gli utenti effettivi possano concedere l'accesso.

Ambiti ristretti (più gravi)

Un numero limitato di ambiti (ad esempio, accesso completo a Gmail) sono Restretti e richiedono un audit di sicurezza di terze parti (CASA) oltre alla verifica.

Risolvi

Per la modalità test - aggiungere utenti di prova
1 Nella Google Cloud Console, vai a API e servizi - Schermata di consenso OAuth.
2 Sotto Test utenti, fare clic Aggiungi utenti e aggiungi l'indirizzo Gmail di ciascun utente che necessita di accesso durante il test.
3 Salva. L'utente può ora autorizzare l'app mentre rimane in modalità di test.
Per la produzione - inviare per verifica + CASA se necessario
1 Assicurati che la tua schermata di consenso OAuth sia completamente compilata: nome dell'app, email di supporto, URL della homepage, URL dell'informativa sulla privacy.
2 Nella pagina dello schermo di consenso OAuth, fai clic su Pubblica App per passare alla Produzione, che attiva l'invio della revisione di verifica per gli ambiti sensibili.
3 Per gli ambiti ristretti, completare una valutazione di sicurezza CASA di livello 2. Vedi la Guida completa alla configurazione di Google OAuth per la verifica e il flusso di lavoro CASA.
concessione_non_valida

invalid_grant: "riconnetti il tuo account Gmail"

Il concessione non valida l'errore è uno dei più confusi in produzione: si interrompe silenziosamente per un sottoinsieme di utenti e richiede un nuovo flusso OAuth per il ripristino. Comprendere il ciclo di vita del token di aggiornamento è la chiave per gestirlo correttamente.

Il messaggio di errore esatto

{"error": "invalid_grant", "error_description": "Token scaduto o revocato."} -- o -- {"error": "invalid_grant", "error_description": "Richiesta non valida"}

Causa: il ciclo di vita del token di aggiornamento

6 mesi di inattività - Google revoca i token di aggiornamento non utilizzati per 6 mesi. Un utente che ha collegato il proprio account e poi ha smesso di utilizzare la tua app riceverà questo errore al tentativo successivo.
L'utente ha cambiato la password di Google - cambiare la password dell'account Google revoca tutti i token OAuth esistenti per quell'account, inclusi i token di aggiornamento rilasciati ad app di terze parti.
Modifica dell'ambito alla ri-autorizzazione - se riautorizzi con un set di ambiti diverso dalla concessione originale, Google revocherà il token di aggiornamento precedente.
Modalità di test = scadenza del token di 7 giorni - mentre la tua app è nello stato di pubblicazione "In test", i token di aggiornamento scadono dopo 7 giorni, indipendentemente dall'uso. Questo è il motivo più comune che gli sviluppatori riscontrano concessione_non_valida dopo una settimana di test.
Codice di autorizzazione utilizzato più di una volta - il codice di autorizzazione restituito da Google nel reindirizzamento OAuth è monouso. Se si chiama l'endpoint del token più di una volta con lo stesso codice, tutte le chiamate successive restituiranno concessione_non_valida.

Correggi: riautorizza con access_type=offline + prompt=consent

build_auth_url.py
from google_auth_oauthlib.flow import Flusso flusso = Flow.from_client_secrets_file( 'client_secrets.json', scope=['https://www.googleapis.com/auth/gmail.readonly'], redirect_uri=REDIRECT_URI ) # access_type=offline → ottenere un token di aggiornamento # prompt=consent → richiede un nuovo consenso, restituisce sempre un nuovo token di aggiornamento auth_url, stato = flusso.url_autorizzazione( tipo_di_accesso='offline', prompt'consenso' ) # Salva il NUOVO refresh_token contenuto nella risposta Il vecchio token # non è più valido: aggiorna il tuo database
Nuovo token di aggiornamento emesso: memorizzalo e scarta quello vecchio

Per evitare concessione_non_valida in produzione: usa sempre access_type=offline e consenso Quando si avvia il flusso OAuth, aggiorna il token di aggiornamento memorizzato ogni volta che l'utente riautorizza, rileva concessione_non_valida errori e attivare un'interfaccia utente di riautorizzazione graduale (un prompt "ricollegare il tuo account Gmail"), e spostare la tua app dalla modalità di test per ottenere token permanenti.

Salta la gestione del token di aggiornamento Amplia su OAuth gestito di Unipile: nessun ciclo di vita del token da gestire
Costruiscilo con Unipile
Console Google Cloud

La schermata di consenso OAuth non viene visualizzata nella Google Cloud Console

Questa è la query di ricerca con il volume più elevato in questo cluster (oltre 390 ricerche mensili). La pagina "Schermata di consenso OAuth" sembra essere scomparsa dalla Google Cloud Console per molti sviluppatori nel periodo 2024-2026 a causa di una riprogettazione dell'interfaccia utente. Non è stata rimossa, si è spostata.

Sintomo

Cosa vedi

Apri la Google Cloud Console e navighi su API e servizi, ma la voce di menu "Schermata di consenso OAuth" è mancante o facendo clic su di essa si viene reindirizzati a una nuova "Panoramica su OAuth" pagina che mostra un dashboard riassuntivo anziché il modulo di configurazione che ti aspettavi.

Cause

1 Google ha ridisegnato la Google Cloud Console nel 2024 e ha spostato la configurazione della schermata di consenso OAuth in una nuova "Panoramica su OAuth" sezione sotto API e Servizi. Il modulo di modifica diretta si trova ora un livello più in basso.
2 Potresti avere Ruolo di visualizzatore invece del ruolo di Editor o Owner sul progetto Google Cloud. Gli account con ruolo Viewer possono vedere la panoramica ma non possono accedere al modulo di configurazione della schermata di consenso.
3 Potresti essere sul progetto sbagliato. Ogni progetto ha la propria schermata di consenso OAuth. Se hai più progetti, controlla il selettore del progetto nella parte superiore della console.
4 Non hai ancora selezionato un Tipo di utente (Interno o Esterno) per la schermata di consenso OAuth. Questa selezione è obbligatoria prima che il modulo di configurazione diventi accessibile.

Correggere (passo dopo passo)

Passaggi per accedere alla configurazione della schermata di consenso OAuth
1 Verifica di essere sul progetto Google Cloud corretto utilizzando il menu a discesa del progetto in alto nella pagina. In caso contrario, passa al progetto in cui è configurato il tuo ID client OAuth.
2 Conferma il tuo ruolo: vai IAM e Amministratore - IAM e verifica di avere Editor o Proprietario Il ruolo Viewer non può modificare la schermata del consenso.
3 Naviga verso API e Servizi - Panoramica OAuth. Vedrai una pagina di riepilogo.
4 Cerca il "Modifica App" pulsante o il "Branding" / "Pubblico" / "Scopi" schede. Queste sono le sezioni di quella che era precedentemente una singola pagina di configurazione "Schermata di consenso OAuth".
5 Se non hai mai configurato una schermata di consenso OAuth in questo progetto, fai clic su Inizio e scegli il tuo tipo di utente: Interno (Solo per utenti dello spazio di lavoro, nessuna verifica necessaria) o Esterno (qualsiasi account Google, verifica richiesta per ambiti sensibili).
6 Compilare tutti i campi obbligatori: nome dell'app, email di supporto e per le App esterne: URL della homepage e URL della politica sulla privacy.
Consiglio rapido: puoi anche navigare direttamente tramite questo pattern di URL (sostituisci IL_TUO_PROJECT_ID): https://console.cloud.google.com/apis/credentials/consent?project=YOUR_PROJECT_ID. Questo deep link bypassa la pagina di panoramica e va direttamente alla configurazione della schermata di consenso. Per una guida completa su ogni campo di configurazione, la selezione del tipo di utente e il limite di 100 utenti per i test, consulta la nostra Guida alla configurazione della schermata di consenso di OAuth.

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.

SOC 2 - GDPR - Nessuna revisione dell'app necessaria - Passa alla tua chiave in qualsiasi momento
CASA Certificato di Livello 2
connect-gmail.shricciolo
# Nessuna Google Cloud Console. Nessuna recensione.#: collega qualsiasi account Gmail in 5 minuti. ricciolo -X POST "https://api.unipile.com/v1/accounts" \ -H ""X-API-KEY: $UNIPILE_KEY"" \ -d '{ "fornitore": "GOOGLE_OAUTH", "use_unipile_credentials": true }'
ambito_non_valido

ambito_non_valido

Un errore di battitura nell'URL dello scope o un'API disabilitata faranno sì che Google rifiuti l'intera richiesta di autorizzazione prima che avvenga qualsiasi interazione con l'utente.

Il messaggio di errore esatto

{"errore": "ambito_non_valido", "descrizione_errore": "Alcuni ambiti richiesti non erano validi. {valid=[https://mail.google.com/], invalid=[gmail.readonly]}"} -- o sull'URL della schermata di consenso -- errore=ambito_non_valido&descrizione_errore=Alcuni+ambiti+richiesti+non+erano+validi

Causa

Due cause profonde comuni: (1) il valore scope è un nome breve come gmail.solodlettura invece dell'URL completo https://www.googleapis.com/auth/gmail.readonly, o (2) l'API di Gmail (o qualsiasi altra API di Google a cui stai facendo riferimento) non è abilitata nel progetto Google Cloud.

Gmail ambito comuni e i loro URL corretti

URL di ambito (utilizzare l'URL completo) Ciò che permette Tipo
https://www.googleapis.com/auth/gmail.readonly Leggi tutti i messaggi e i thread Sensibile
https://www.googleapis.com/auth/gmail.send Invia email per conto dell'utente Sensibile
https://www.googleapis.com/auth/gmail.modify Leggi, componi, invia, elimina thread Sensibile
https://mail.google.com/ Accesso completo alla casella di posta (IMAP/SMTP) Restricted
https://www.googleapis.com/auth/userinfo.email Leggere solo l'indirizzo email dell'utente Base
https://www.googleapis.com/auth/gmail.readonly Leggi tutti i messaggi e i thread Sensibile
https://www.googleapis.com/auth/gmail.send Invia email per conto dell'utente Sensibile
https://www.googleapis.com/auth/gmail.modify Leggi, componi, invia, elimina thread Sensibile
https://mail.google.com/ Accesso completo alla casella di posta (IMAP/SMTP) Restricted

Risolvi

Passaggi per correggere invalid_scope
1 Verifica di utilizzare la URL completo inizia con https://www.googleapis.com/auth/ o https://mail.google.com/. Non usare mai la forma abbreviata come gmail.solodlettura.
2 Nella Google Cloud Console, vai a API e servizi - API e servizi abilitati. Ricerca per API Gmail e confermare che sia visualizzato come "Abilitato". In caso contrario, fare clic su Abilita.
3 Conferma che lo scopo è elencato nella tua schermata di consenso OAuth sotto Ambiti per le API Google. Se manca, aggiungilo.
4 Ri-testa il tuo URL di autorizzazione. Per un elenco completo degli ambiti Gmail validi e della loro classificazione di sensibilità, vedi la Guida agli scope dell'API di Gmail.
Verifica

"Google non ha verificato questa app" e il limite di 100 utenti

La schermata di avviso "Google non ha verificato questa app" appare quando un'app non verificata richiede ambiti sensibili o riservati. Sebbene gli utenti possano procedere facendo clic su "Avanzate" e poi su "Vai a [nome app] (non sicuro)", questa soluzione non è adatta per la produzione e la modalità di test limita l'app a un massimo di 100 utenti unici in totale.

Causa

Causa principale

Quando la tua app richiede ambiti sensibili (come gmail.solodlettura o gmail.invia), Google mostra questa schermata di avviso a ogni utente finché non completerai la revisione di verifica. Per gli ambiti limitati, sarà inoltre necessario superare un audit di sicurezza di terze parti (CASA Livello 2).

Mentre lo stato di pubblicazione è "In test", questa schermata di avviso viene visualizzata anche per gli utenti di test e il numero totale di utenti di test consentiti è limitato a 100. I token per gli utenti di test scadono dopo 7 giorni.

Risolvi

Percorso verso la produzione per ambiti sensibili/con restrizioni
1 Completa la schermata di consenso OAuth: nome dell'app, email di supporto, URL della home page e URL dell'informativa sulla privacy devono essere tutti forniti.
2 Nella schermata di consenso OAuth / pagina dell'audience, fai clic Pubblica App (sposta lo stato da Testing a Production, attivando il flusso di verifica di Google).
3 Per ambiti sensibili: completa Revisione di verifica di Google. Ciò comporta la conferma della tua identità, la spiegazione dell'uso di ogni ambito sensibile e il collegamento di un video di YouTube che dimostra il flusso OAuth.
4 Per ambiti ristretti (ad esempio. https://mail.google.com/inoltre completa un CASA Livello 2 valutazione di sicurezza da parte di un valutatore approvato da Google.
5 Per la configurazione completa dello schermo di consenso, la selezione dell'ambito e il flusso di verifica passo dopo passo, vedere Verifica dell'app Google e guida CASA.
Intermediario tecnico indipendente

Questi errori scompaiono quando il progetto OAuth è già certificato

La schermata "Google non ha verificato questa app", il limite di 100 utenti e la scadenza del token di 7 giorni in modalità Test sono tutti sintomi di possedere e gestire il proprio progetto Google Cloud. Un intermediario tecnico indipendente che agisce per conto di ciascun utente autenticato - e ha già completato la certificazione CASA di Livello 2 - rimuove completamente questo overhead dal tuo lato. I tuoi utenti autorizzano una volta; il ciclo di vita del token, la conformità all'ambito e la verifica ripetuta vengono gestiti a livello di piattaforma.

Questo non è un workaround per la revisione di sicurezza di Google. Unipile ha completato in modo indipendente il livello 2 CASA e non è affiliata, approvata o sponsorizzata da Google.

Nave su OAuth Google già certificato
Strategia

Come evitare questa intera classe di errori di Google OAuth

Osservando tutti e 7 gli errori di Google OAuth in questa guida, emerge uno schema. Ognuno di essi ha la stessa origine: la gestione manuale del proprio progetto Google Cloud e della sua configurazione OAuth. Questi errori di Google OAuth non sono casuali: sono conseguenze strutturali della proprietà di un progetto OAuth non verificato, da discrepanze negli URI di reindirizzamento e fallimenti nella rotazione dei token al limite dei 100 utenti e ai rifiuti della schermata di consenso.

C'è un altro modo. Usando un intermediario tecnico indipendente che agisce per conto di ciascun utente autenticato - uno che ha già completato la revisione di verifica di Google e la certificazione di sicurezza CASA Tier 2 - elimina tutte queste modalità di errore dal tuo carico di lavoro. Il confronto sottostante mostra esattamente quali errori scompaiono e quale infrastruttura gestisce Unipile. Vedi il Documentazione Unipile su Google OAuth per la guida completa all'integrazione.

Riparare da soli vs. Unipile

Ogni errore in questa guida: chi possiede la correzione?

I 7 errori di Google OAuth trattati sopra condividono una radice comune: possiedi il progetto Google Cloud, quindi possiedi ogni modalità di errore. Ecco un confronto affiancato di cosa ciò significa in pratica.

Ripararlo da soli La vostra responsabilità
redirect_uri_mismatch Gestisci ogni URI di reindirizzamento nella Google Cloud Console
admin_policy_enforced Dipende dall'amministratore Workspace di ciascun utente - fuori dal tuo controllo
accesso_negato / app bloccata Processo di verifica di Google + gestione utenti di test
concessione_non_valida Costruisci e mantieni la tua logica di rotazione dei refresh token
Problemi con la schermata di consenso Configura e mantieni la schermata di consenso OAuth da solo
ambito_non_valido Tieni traccia di quali ambiti con restrizioni richiedono la verifica di Google
App non verificata + limite di 100 utenti Esegui autonomamente la verifica di Google e la valutazione CASA di livello 2
Ti occupi di tutto e ne risolvi i problemi
Con Unipile Manipolato
Link di autenticazione ospitato - nessuna schermata di consenso da configurare Nessuna gestione degli URI di reindirizzamento, mai
URI di reindirizzamento gestiti per te redirect_uri_mismatch non può verificarsi
Token di aggiornamento gestiti automaticamente Nessun errore di "riconnetti il tuo Gmail" che raggiunge i tuoi utenti
Collega alla chiave OAuth Google già certificata di Unipile Nessun avviso di app non verificata, nessun limite di 100 utenti
CASA Certificato di Livello 2 Chiave OAuth di Google di Unipile - intermediario tecnico indipendente
Salta la creazione e la certificazione del tuo progetto Google Cloud: collega le Gmail dei tuoi utenti sulla chiave già certificata di Unipile, poi passa alla tua quando sarai pronto (BYOC)
Accedi agli ambiti Gmail con restrizioni senza attendere il completamento della verifica di Google
Unipile agisce come intermediario tecnico indipendente, elaborando richieste per conto di ciascun utente autenticato
Spedisci ora con la chiave certificata Unipile - possiedila in seguito Inizia oggi a collegare gli account Gmail dei tuoi utenti tramite la chiave Google OAuth certificata CASA Tier 2 di Unipile. Esegui parallelamente la tua verifica Google Cloud. Quando sarà approvata, passa alle tue credenziali con Bring Your Own Credentials (BYOC): i tuoi utenti vedranno il tuo marchio, Unipile continuerà a gestire l'infrastruttura.
Queste classi di errore semplicemente non si verificano

La distinzione chiave: Unipile ha già completato la revisione di sicurezza di Google e la valutazione di livello 2 CASA per le connessioni che gestisce per tuo conto. Non si tratta di un aggiramento della revisione di sicurezza di Google: Unipile l'ha già superata. I tuoi utenti ottengono una schermata di consenso pulita (nessun avviso di "app non verificata"), la tua app viene distribuita immediatamente e puoi procedere con la tua verifica Google Cloud in parallelo senza alcuna pressione di scadenze di produzione.

Crea la tua integrazione Gmail senza toccare Google Cloud Console Collega account Gmail sulla chiave Google OAuth già certificata di Unipile. Nessuna configurazione di URI di reindirizzamento, nessuna logica di rotazione dei token, nessun avviso di app non verificata per i tuoi utenti.
Nave sulla chiave certificata di Unipile

Nota sulla conformità: Unipile è un intermediario tecnico indipendente, non affiliata, approvata o sponsorizzata da Google. Il client OAuth di Google di Unipile è certificato CASA di Livello 2, consentendo ai tuoi utenti di autorizzare l'accesso a Gmail senza un avviso di "app non verificata" per le connessioni mediate da Unipile. Questa non è una soluzione alternativa alla revisione di sicurezza di Google: Unipile l'ha già superata per le connessioni che media. per conto di ciascun utente autenticato. Gli utenti possono revocare l'accesso in qualsiasi momento tramite la pagina delle autorizzazioni del loro Account Google.

Unipile - FAQ sugli errori di Google OAuth

Domande frequenti sugli errori di Google OAuth

Risposte alle domande più comuni sugli errori di Google OAuth e sugli errori dell'API Gmail, che coprono il ciclo di vita dei token, le policy degli amministratori, gli URI di reindirizzamento e la configurazione della Google Cloud Console.

01 admin_policy_enforced significa che una policy, ovvero una regola o un'impostazione, è stata applicata o imposta dall'amministratore (admin) di un sistema o servizio.

admin_policy_enforced significa che un super amministratore di Google Workspace ha impedito che la tua app o gli specifici ambiti OAuth da essa richiesti vengano autorizzati dagli utenti di tale organizzazione. È una policy di controllo degli accessi organizzativi, non un bug nel tuo codice. La soluzione richiede un'azione da parte del super amministratore di Workspace nella Google Admin Console alla voce Sicurezza > Controlli API > Gestisci accesso app di terze parti.

No. Un utente normale non può risolvere admin_policy_enforced. Solo un Google Workspace superamministratore puoi risolvere questo errore contrassegnando l'app come attendibile nella Console di amministrazione. L'utente interessato deve contattare il proprio amministratore IT o l'amministratore principale di Workspace e richiedere che la specifica app OAuth venga aggiunta all'elenco approvato.

Il redirect_uri_mismatch su localhost accade quando l'URI che registri nella Google Cloud Console non corrisponde esattamente all'URI utilizzato dal tuo server di sviluppo locale. Ad esempio, registrando http://localhost:3000/callback ma in esecuzione sulla porta 3001, o dimenticando uno slash finale. Google consente http:// (non solo https://per le URI di localhost. Registra l'URI esatta utilizzata dal tuo server locale, incluso il numero di porta corretto.

No. Le origini JavaScript autorizzate e gli URI di reindirizzamento autorizzati sono due campi separati. Le origini JavaScript sono utilizzate solo per i flussi OAuth lato browser. Per risolvere redirect_uri_mismatch, devi aggiungere l'URI a URI di reindirizzamento autorizzati campo, non alle origini di JavaScript.

Un singolo client OAuth 2.0 di Google può avere fino a 100 URI di reindirizzamento autorizzati registrato. Ciò consente di registrare URI per diversi ambienti (sviluppo locale, staging, produzione) e diversi percorsi di callback all'interno dello stesso client.

Se la tua app è in Test dello stato di pubblicazione, i token di aggiornamento di Google scadono dopo 7 giorni indipendentemente dall'uso. Questo è intenzionale per le app non verificate. Passa allo stato Produzione facendo clic su Pubblica App nella pagina della schermata di consenso OAuth per ottenere token di lunga durata. In produzione, i token di aggiornamento rimangono validi finché l'utente utilizza la tua app almeno una volta ogni 6 mesi. Per un'alternativa gestita, visita il nostro soluzione Gmail API gestita.

Google revoca i token di aggiornamento che non sono stati utilizzati per 6 mesi (circa 180 giorni). I token vengono revocati anche quando: l'utente cambia la password del proprio account Google, l'utente revoca l'accesso all'app nelle impostazioni di sicurezza del proprio account Google, si autorizza nuovamente con ambiti diversi o il numero totale di token di aggiornamento per una singola coppia utente-app supera 50 (i più vecchi vengono revocati per primi). Per una panoramica completa sulla creazione di integrazioni email robuste, consulta il nostro Guida completa all'API email.

Google ha ridisegnato la Cloud Console nel 2024. La configurazione della schermata di consenso OAuth è ora all'interno API e Servizi > Panoramica OAuth. Clicca Modifica app o utilizza le schede Branding, Audience e Scopes. Controlla anche: hai bisogno Ruolo di Editor o Proprietario sul progetto (Lo spettatore non può accedere al modulo) e assicurati di essere sul progetto corretto utilizzando il selettore del progetto in cima alla console.

Stai ancora riscontrando un errore di Google OAuth non elencato qui? Salta il debug e lascia che Unipile gestisca l'autenticazione OAuth di Gmail per te.

Crea ora
it_ITIT