Scegli un modello di autorizzazione dell'utente

Questa guida ti aiuta a scegliere se utilizzare la libreria di servizi Google Identity per l'autorizzazione degli utenti o se implementare la tua libreria JavaScript. che ti aiuta a decidere quale flusso di autorizzazione OAuth 2.0 è la più adatta alla tua applicazione web.

Prima di leggere questa guida, si presume che tu conosca i termini e i concetti descritti nella guida Panoramica e Come funziona l'autorizzazione degli utenti.

La libreria GIS viene eseguita in questi browser supportati sul dispositivo dell'utente. Non è destinato a essere utilizzato con framework JavaScript lato server come Node.js, ma utilizza la libreria client GoogleNode.jsdi Google.

Questa guida riguarda solo gli argomenti di autorizzazione e condivisione dei dati. Non vede l'autenticazione degli utenti, ma consulta Accedi con Google e la guida Migrazione da Accedi con Google per la registrazione e l'accesso degli utenti.

Decidere se la libreria GIS è giusta per te

Devi scegliere se utilizzare la libreria di Google o crearne di personalizzate in base alle tue esigenze. Una panoramica di caratteristiche e funzionalità:

  • La libreria JavaScript di Identity Services di Google implementa:
    • Il flusso di consenso basato su popup si riduce al minimo i reindirizzamenti, consentendo così 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 degli utenti.
    • Gestione degli errori umana e link alla documentazione utilizzati dagli ingegneri durante lo sviluppo e in un secondo momento per i visitatori del tuo sito.
  • Quando implementi senza la libreria Servizi di identità, sei responsabile:
    • Gestione delle richieste e delle risposte con gli endpoint OAuth 2.0 di Google, inclusi i reindirizzamenti.
    • Ottimizzare l'esperienza utente.
    • Implementazione di funzionalità di sicurezza per convalidare le richieste, le risposte e per prevenire i CSRF.
    • Metodi per confermare che un utente ha concesso il consenso per qualsiasi ambito richiesto.
    • Gestione dei codici di errore OAuth 2.0, creazione di messaggi leggibili e umani e collegamenti all'assistenza utente.

In breve, Google offre la libreria GIS per aiutarti a implementare in modo rapido e sicuro un client OAuth 2.0 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, a prescindere dal fatto che tu decida di utilizzare la libreria JavaScript di Google Identity Servizi 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 l'app chiama le API Google senza l'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 di sicurezza utente più elevati o più bassi.

Quando confronti i flussi e valuti i requisiti di sicurezza, devi tenere conto del fatto che il livello di sicurezza dell'utente varia in base agli ambiti che scegli. Ad esempio, la visualizzazione degli inviti di calendario in sola lettura potrebbe essere considerata meno rischiosa rispetto all'utilizzo di un ambito di lettura/scrittura per modificare i file su Drive.

Confronto dei flussi OAuth 2.0

Flusso implicito Flusso del codice di autorizzazione
Consenso degli utenti obbligatorio Per ogni richiesta di token, inclusa la sostituzione di token scaduti. Solo per la prima richiesta di token.
L'utente deve essere presente No, supporta l'utilizzo offline.
Sicurezza degli utenti Minima La maggior parte ha l'autenticazione client ed evita i rischi di gestione dei token nel browser.
Token di accesso emesso
Token di aggiornamento emesso No
Browser supportato obbligatorio
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 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.
Archiviazione sicura necessaria 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 scadenza token di accesso Per richiedere e ottenere un nuovo token di accesso valido è necessario un gesto dell'utente come la pressione di un pulsante o il clic su un link. Dopo una richiesta dell'utente iniziale, la tua piattaforma scambia il token di aggiornamento memorizzato per ottenere un nuovo token di accesso valido necessario per chiamare le API di Google.