In questa guida ti guideremo su come risolvere il problema per cui non puoi accedere a questa app perché non è conforme alla politica OAuth 2.0 di Google. Quindi, se stai navigando in Internet da ore per superare la situazione, puoi fare affidamento su questo blog. Quindi, senza ulteriori indugi, iniziamo. Ma prima parliamo della politica OAuth 2.0 di Google.
Che cos’è OAuth?
Il protocollo OAuth (Open Authorization) è stato sviluppato dalla Internet Engineering Task Force e consente un accesso delegato sicuro. Consente a un’app di accedere a una risorsa controllata da qualcun altro (utente finale). Questo tipo di accesso necessita di token, che rappresentano il diritto di accesso delegato. Ecco perché le applicazioni ottengono l’accesso senza impersonare l’utente che controlla la risorsa.
In questo blog abbiamo cercato di fornire alcuni passaggi per rispettare le norme OAuth 2.0 di Google. In modo che tu possa seguire le linee guida per essere conforme ai problemi più comuni incontrati dagli sviluppatori durante la preparazione della tua app per la produzione. Ti aiuterà a raggiungere il pubblico più vasto possibile con errori limitati.
Utilizzare progetti separati per test e produzione
I criteri OAuth di Google richiedono progetti separati per il test e la produzione. Alcuni dei criteri e dei requisiti vengono applicati solo alle app di produzione. Potrebbe quindi essere necessario creare e configurare un progetto separato che includa client OAuth che corrisponda alla versione di produzione della tua app disponibile per tutti gli account Google.
I client OAuth di Google vengono utilizzati nella produzione e aiutano a fornire un ambiente di raccolta e archiviazione dei dati prevedibile, più stabile e sicuro rispetto agli stessi client OAuth che testano o eseguono il debug della stessa app. Il tuo progetto di produzione può essere sottoposto alla verifica e quindi essere soggetto a requisiti aggiuntivi per specifici ambiti API, che probabilmente includono valutazioni di sicurezza di terze parti.
Passaggio 1: vai alla console API di Google, tocca Crea progetto, inserisci il nome e tocca Crea
Passaggio 2: quindi esamina i client OAuth nell’ambito del progetto che potrebbe essere collegato al tuo livello di test. Se applicabile, crea clienti OAuth simili per i clienti di produzione nel progetto di produzione.
Passaggio 3: quindi abilita tutte le API utilizzate dai tuoi clienti
Passaggio 4: dopodiché, esamina la configurazione della schermata di consenso OAuth nel nuovo progetto.
I client Google OAuth utilizzati nella produzione non devono avere ambienti di test, URI di reindirizzamento o origini Java Script disponibili solo per te o per il tuo team di sviluppo, abbiamo elencato alcuni esempi:
- I server di prova dei singoli sviluppatori
- Versioni di prova o pre-release dell’app
Mantenere un elenco di contatti rilevanti per il progetto
Google e le singole API che hai abilitato potrebbero doverti contattare in merito alle modifiche ai suoi servizi o alle nuove configurazioni richieste al progetto e ai suoi clienti. Ora esamina gli elenchi IAM del progetto per assicurarti che le persone importanti del tuo team abbiano accesso per modificare o visualizzare la configurazione del tuo progetto. Tieni presente che questi account potrebbero anche ricevere e-mail sulle modifiche necessarie al progetto.
Il ruolo consiste in un insieme di autorizzazioni che consentono all’utente di eseguire azioni particolari sulle risorse del progetto. Gli editor di progetto hanno l’autorizzazione per le azioni che modificano lo stato, come la possibilità di apportare modifiche alla schermata di consenso OAuth del progetto. I proprietari del progetto che dispongono di tutte le autorizzazioni di editor possono aggiungere o eliminare account collegati al progetto o eliminare il progetto. I proprietari del progetto possono anche offrire un contesto sul motivo per cui potrebbero essere impostate le informazioni di fatturazione. I proprietari del progetto possono impostare le informazioni di fatturazione per un progetto che utilizza API a pagamento.
I Project Owner e gli editori dovrebbero essere tenuti aggiornati. Puoi aggiungere diversi account correlati al progetto per aiutarti. Assicurare un accesso continuo al progetto e alla relativa manutenzione. Le e-mail vengono ricevute da quegli account che hanno notifiche sul progetto o aggiornamenti ai nostri servizi. Gli amministratori di Google Cloud Organization devono assicurarsi che un contatto accessibile sia collegato a ogni progetto nell’organizzazione. E se non ci sono informazioni di contatto aggiornate per il tuo progetto, è probabile che perderai i messaggi obbligatori che richiedono la tua azione.
Avvertenza: la mancata adozione di notifiche tempestive sul progetto potrebbe comportare la perdita di accesso alle API di Google.
Punti da ricordare: uno dei contatti rilevanti per il progetto è l’e-mail di supporto utente configurata per la schermata di consenso OAuth. E se gli utenti hanno problemi con la tua app o gli amministratori di Google Cloud Organization hanno domande per conto dei loro utenti e questo indirizzo email viene visualizzato in modo che possano entrare in contatto.
Rappresenta accuratamente la tua identità
Devi fornire un nome dell’app autentico, facoltativamente, un logo da mostrare agli utenti. Queste informazioni sul marchio possono rappresentare esattamente l’identità dell’applicazione. Le informazioni sul marchio dell’app vengono configurate dalla pagina della schermata di consenso OAuth.
E per le app di produzione, le informazioni sul marchio definite nella schermata di consenso OAuth devono essere confermate prima che vengano visualizzate agli utenti. Gli utenti potrebbero essere più inclini a concedere l’accesso all’app al termine della verifica del marchio. Le informazioni di base sull’applicazione, che includono il nome dell’app, la home page, i termini di servizio e le norme sulla privacy, vengono mostrate agli utenti nella schermata di concessione e quando esaminano le concessioni esistenti o agli amministratori di Google Workspace che esaminano l’utilizzo dell’app da parte della propria organizzazione
Google può revocare o sospendere l’accesso al servizio API di Google e agli altri prodotti e servizi Google per le app che falsificano la propria identità o tentano di fuorviare gli utenti.
Richiedi solo gli ambiti che desideri
Durante lo sviluppo della tua applicazione, potresti aver utilizzato un ambito di esempio offerto dall’API per creare una prova di concetto all’interno della tua applicazione al fine di saperne di più sulle caratteristiche e le funzionalità delle API. Questi ambiti di esempio richiedono spesso più informazioni rispetto a quelle necessarie per l’implementazione finale dell’app, poiché offrono una copertura ad ampio raggio di tutte le possibili azioni per un’API specifica.
Ad esempio: l’ambito di esempio può richiedere autorizzazioni di lettura, scrittura ed eliminazione mentre l’applicazione necessita solo di autorizzazioni di lettura, richiedere autorizzazioni pertinenti che sono limitate alle informazioni critiche essenziali per implementare l’applicazione.
Ora esamina la documentazione di riferimento per l’endpoint API che la tua app chiama e prendi nota degli ambiti di cui ha bisogno per accedere ai dati correlati richiesti dalla nostra app. Quindi esamina tutte le guide all’autorizzazione offerte dall’API e descrive gli ambiti in modo più dettagliato per includere l’utilizzo più comune. Seleziona l’accesso ai dati minimo richiesto dalla tua applicazione per alimentare le funzionalità associate.
Invia app di produzione che utilizzano ambiti riservati o limitati per la verifica
Ebbene, alcuni ambiti sono classificati come “sensibili” o “limitati” e non possono essere utilizzati nelle app di produzione senza revisione. È necessario immettere tutti gli ambiti utilizzati dall’app di produzione nella configurazione della schermata di consenso OAuth. Tieni presente che se la tua app di produzione utilizza ambiti sensibili o limitati, devi inviare l’utilizzo degli ambiti per la verifica prima di includere gli ambiti in una richiesta di autorizzazione.
Usa solo domini di tua proprietà
Il processo di verifica della schermata del consenso OAuth di Google richiede la verifica di tutti i domini relativi alla home page del progetto, alle norme sulla privacy, ai termini di servizio, agli URI di reindirizzamento autorizzati o alle origini di script Java autorizzati. Quindi rivedi l’elenco dei domini in uso dalla tua app e riepilogati nella sezione Domini autorizzati dell’editor della schermata di consenso OAuth, quindi riconosci tutti i domini che non possiedi e che quindi non potresti verificare. Per verificare la proprietà dei domini autorizzati del progetto, utilizza Google Search Console. Successivamente, utilizza l’account Google correlato al progetto della console API come proprietario o editor.
E se il tuo progetto utilizza un fornitore di servizi con un dominio condiviso regolare, ti consigliamo di abilitare le configurazioni che potrebbero consentire l’uso del tuo dominio. Alcuni provider offrono di mappare i loro servizi al sottodominio di un dominio che già possiedi.
Usa URI di reindirizzamento sicuro e origini JavaScript
I client OAuth 2.0 per le pagine Web devono proteggere i propri dati che utilizzano URI di reindirizzamento HTTPS e origini JavaScript, non HTTP semplice. Google può rifiutare le richieste OAuth che non si avviano o non si risolvono in un contenuto protetto.
Ora considera quali applicazioni e script di terze parti potrebbero avere accesso ai token e alle altre credenziali utente che tornano a quella pagina. Ora limitare l’accesso ai dati sensibili reindirizzerà le posizioni URI che sono limitate alla verifica e alla memorizzazione dei dati dei token.
Prossimi passi
Dopo esserti assicurato che la tua app sia conforme alle norme OAuth 2.0 nella pagina, consulta Invia per la verifica del marchio per i dettagli sul processo di verifica.
Conclusione
Questo è tutto sul fatto che non puoi accedere a questa app perché non è conforme alle norme OAuth 2.0 di Google. Spero che il blog ti sia piaciuto. Grazie per aver letto.