Questa guida ti aiuta a scegliere se utilizzare la libreria dei Servizi di identità Google per l'autorizzazione degli utenti o se implementare la tua libreria JavaScript. Ti aiuta a decidere quale flusso di autorizzazione OAuth 2.0 è più adatto alla tua applicazione web.
Prima di leggere questa guida, si presume che tu conosca i termini e i concetti descritti nelle guide Panoramica e Come funziona l'autorizzazione dell'utente.
La libreria GIS viene eseguita in questi browser supportati sul dispositivo dell'utente. Non è destinato all'utilizzo con framework JavaScript lato server come Node.js. Utilizza invece la libreria client Node.js di Google.
Questa guida tratta solo gli argomenti relativi all'autorizzazione e alla condivisione dei dati. Questa versione non esamina l'autenticazione degli utenti; consulta invece Accedi con Google e la guida alla migrazione da Accedi con Google per la registrazione e l'accesso degli utenti.
Decidere se la Libreria GIS è adatta alle proprie esigenze
Devi scegliere se utilizzare la libreria di Google o crearne una personalizzata che risponda al meglio alle tue esigenze. Una panoramica delle caratteristiche e delle funzionalità:
- La libreria JavaScript dei servizi di identità di Google implementa:
- Flussi di consenso basati su popup per ridurre al minimo i reindirizzamenti, consentendo così agli utenti di rimanere sul tuo sito per tutta la durata del processo di autorizzazione.
- Funzionalità di sicurezza come Cross-site Request Forgery (CRSF).
- Metodi di supporto per richiedere singoli ambiti e confermare il consenso dell'utente.
- Link alla documentazione e alla gestione degli errori di facile utilizzo da parte dei tecnici durante lo sviluppo e in seguito per i visitatori del tuo sito.
- In caso di implementazione senza la libreria dei Servizi di identità, sei responsabile di:
- Gestione di richieste e risposte con gli endpoint OAuth 2.0 di Google, inclusi i reindirizzamenti.
- Ottimizzare l'esperienza utente.
- Implementazione di funzionalità di sicurezza per convalidare richieste, risposte e prevenire CSRF.
- Metodi per verificare che un utente abbia concesso il consenso per gli ambiti richiesti.
- Gestione dei codici di errore OAuth 2.0, creazione di messaggi leggibili e link alla guida per l'utente.
In breve, Google offre la libreria GIS per aiutarti a implementare un client OAuth 2.0 in modo rapido e sicuro e a ottimizzare l'esperienza di autorizzazione dell'utente.
Scelta di un flusso di autorizzazione
Dovrai scegliere uno dei due flussi di autorizzazione OAuth 2.0: implicito o codice di autorizzazione, indipendentemente dal fatto che tu decida di utilizzare la libreria JavaScript dei Servizi di identità Google o di creare la tua libreria.
Entrambi i flussi generano un token di accesso che può essere utilizzato per chiamare le API di Google.
Le differenze principali tra i due flussi sono:
- il numero di azioni utente,
- se la tua app chiama le API di Google in assenza dell'utente,
- se è necessaria una piattaforma di backend per ospitare un endpoint e archiviare i token di aggiornamento per utente per i singoli account utente
- livelli più alti o più bassi di sicurezza dell'utente.
Quando confronti i flussi e valuti i requisiti di sicurezza, un fattore da considerare è che il livello di sicurezza dell'utente varia a seconda degli ambiti scelti. Ad esempio, visualizzare gli inviti del calendario come di sola lettura potrebbe essere considerata meno rischiosa rispetto all'utilizzo di un ambito di lettura/scrittura per modificare i file su Drive.
Confronto del flusso OAuth 2.0
| Flusso implicito | Flusso del codice di autorizzazione | |
| Consenso dell'utente obbligatorio | Per ogni richiesta di token, inclusa la sostituzione dei token scaduti. | Solo per la prima richiesta di token. |
| L'utente deve essere presente | Sì | No, supporta l'utilizzo offline. |
| Sicurezza degli utenti | Minima | La maggior parte prevede l'autenticazione del client ed evita i rischi legati alla gestione dei token nel browser. |
| Token di accesso emesso | Sì | Sì |
| Token di aggiornamento emesso | No | Sì |
| È necessario un browser supportato | Sì | Sì |
| Token di accesso utilizzato per chiamare le API di Google | solo da un'app web in esecuzione nel browser dell'utente. | da un server in esecuzione su una piattaforma di backend o da un'app web in esecuzione nel browser dell'utente. |
| Richiede una piattaforma di backend | No | Sì, per l'hosting e l'archiviazione degli endpoint. |
| È necessario spazio di archiviazione sicuro | No | Sì, per l'archiviazione dei token di aggiornamento. |
| Richiede l'hosting di un endpoint del codice di autorizzazione | No | Sì, per ricevere codici di autorizzazione da Google. |
| Comportamento della scadenza dei token di accesso | Per richiedere e ottenere un nuovo token di accesso valido, è necessario un gesto dell'utente come premere un pulsante o fare clic su un link. | Dopo una richiesta iniziale dell'utente, la tua piattaforma scambia il token di aggiornamento memorizzato per ottenere un nuovo token di accesso valido necessario per chiamare le API di Google. |