Questa guida ti aiuta a scegliere se utilizzare la libreria dei Servizi di identità Google per l'autorizzazione degli utenti o implementare la tua libreria JavaScript. Ti aiuta a decidere quale flusso di autorizzazione OAuth 2.0 è il migliore per la tua applicazione web.
Prima di leggere questa guida, si presuppone che tu abbia familiarità con i termini e i concetti descritti nella guida Panoramica e Come funziona l'autorizzazione utente.
La libreria GIS viene eseguita in questi browser supportati sul dispositivo dell'utente. Non è destinato all'uso con framework JavaScript lato server come Node.js. Utilizza invece la libreria client Node.js di Google.
Questa guida tratta solo argomenti relativi all'autorizzazione e alla condivisione dei dati. Non esamina l'autenticazione utente. Per informazioni su registrazione e accesso degli utenti, consulta Accedi con Google e la guida Migrazione dalla funzionalità Accedi con Google.
Decidere se la libreria GIS è adatta alle tue esigenze
Devi scegliere se utilizzare la libreria di Google o creare la tua soluzione migliore in base alle tue esigenze. Panoramica delle funzionalità:
- La libreria JavaScript dei Servizi di identità Google implementa:
- Flussi di consenso basati su finestre di dialogo per ridurre al minimo i reindirizzamenti, consentendo agli utenti di rimanere sul tuo sito durante la procedura di autorizzazione.
- Funzionalità di sicurezza come Cross-site Request Forgery (CRSF).
- Metodi helper per richiedere singoli ambiti e confermare il consenso dell'utente.
- Gestione degli errori e link alla documentazione di facile utilizzo per gli ingegneri durante lo sviluppo e in seguito per i visitatori del tuo sito.
- Quando implementi senza la libreria Identity Services, sei responsabile di:
- Gestione di richieste e risposte con gli endpoint OAuth 2.0 di Google, inclusi i reindirizzamenti.
- Ottimizzazione dell'esperienza utente.
- Implementazione di funzionalità di sicurezza per convalidare richieste, risposte e per prevenire attacchi CSRF.
- Metodi per confermare che un utente ha concesso il consenso per tutti gli ambiti richiesti.
- Gestione dei codici di errore OAuth 2.0, creazione di messaggi leggibili e link alla guida per l'utente.
In sintesi, Google offre la libreria GIS per aiutarti a implementare in modo rapido e sicuro un client OAuth 2.0 e ottimizzare l'esperienza di autorizzazione dell'utente.
Scegliere 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 una libreria personalizzata.
Entrambi i flussi generano un token di accesso che può essere utilizzato per chiamare le API di Google.
Le principali differenze tra i due flussi sono:
- il numero di azioni utente
- se la tua app chiamerà le API di Google senza la presenza 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 e
- livelli di sicurezza degli utenti più alti o più bassi.
Quando confronti i flussi e valuti i tuoi requisiti di sicurezza, un fattore da considerare è che il livello di sicurezza dell'utente varia a seconda degli ambiti che scegli. Ad esempio, la visualizzazione degli inviti del calendario in modalità di sola lettura potrebbe essere considerata meno rischiosa rispetto all'utilizzo di un ambito di lettura e scrittura per modificare i file in Drive.
Confronto tra i flussi 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'uso offline. |
| Sicurezza degli utenti | Più bassa | La maggior parte ha l'autenticazione del client ed evita i rischi di gestione dei token nel browser. |
| Token di accesso emesso | Sì | Sì |
| Token di aggiornamento emesso | No | Sì |
| Browser supportato richiesto | 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 sulla piattaforma 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 uno spazio di archiviazione sicuro | No | Sì, per l'archiviazione del token di aggiornamento. |
| Richiede l'hosting di un endpoint del codice di autorizzazione | No | Sì, per ricevere codici di autorizzazione da Google. |
| Comportamento di scadenza del token di accesso | Per richiedere e ottenere un nuovo token di accesso valido, è necessaria un'attivazione dall'utente, ad esempio la pressione di un pulsante o il 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. |