Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
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.
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.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2023-12-01 UTC."],[[["\u003cp\u003eThis guide helps developers choose between Google Identity Services or a custom JavaScript library for OAuth 2.0 authorization in their web applications.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Identity Services offers pre-built security features, optimized user experience, and easier implementation compared to building a custom solution.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers need to select between the Implicit or Authorization Code flow based on security, user presence requirements, and backend needs.\u003c/p\u003e\n"],["\u003cp\u003eAuthorization Code flow is recommended for enhanced security, offline access, and refresh token management through a backend server.\u003c/p\u003e\n"],["\u003cp\u003eThe guide assumes prior knowledge of OAuth 2.0 concepts and focuses solely on authorization and data sharing, not user authentication.\u003c/p\u003e\n"]]],[],null,["# Choose a user authorization model\n\nThis guide helps you to choose between using the Google Identity Services\nlibrary for user authorization or implementing your own JavaScript library. It\nhelps you decide which OAuth 2.0 authorization flow is best for your web\napplication.\n\nPrior to reading this guide it is assumed that you are familiar with the terms\nand concepts described in the [Overview](/identity/oauth2/web/guides/overview) and\n[How user authorization works](/identity/oauth2/web/guides/how-user-authz-works) guide.\n\nThe GIS library runs in these [supported browsers](/identity/gsi/web/guides/supported-browsers) on the user's device. It\nis not intended for use with server-side JavaScript frameworks such as Node.js,\ninstead use Google's [Node.js](https://github.com/googleapis/google-api-nodejs-client)\nclient library.\n\nThis guide only covers authorization and data sharing topics. It does not review\nuser authentication, instead see [Sign In With Google](/identity/gsi/web) and the [Migrating\nfrom Google Sign-In](/identity/gsi/web/guides/migration) guide for user sign-up and sign-in.\n\nDeciding if the GIS library is right for you\n--------------------------------------------\n\nYou must choose if using Google's library, or creating your own best fits your\nneeds. An overview of features and functionality:\n\n- Google's Identity Services JavaScript library implements:\n - Popup based consent flows to minimize redirects, thus enabling users to remain on your site throughout the authorization process.\n - Security features such as Cross-site Request Forgery (CRSF).\n - Helper methods to request individual scopes and confirm user consent.\n - Human friendly error handling and documentation links for use by engineers during development and later for visitors to your site.\n- When implementing without the Identity Services library you are responsible for:\n - Managing requests and responses with Google's OAuth 2.0 endpoints, including redirects.\n - Optimizing the user experience.\n - Implementation of security features to validate requests, responses, and to prevent CSRF.\n - Methods to confirm a user has granted consent for any requested scopes.\n - Managing OAuth 2.0 error codes, creating human readable messages, and links to user help.\n\nIn summary, Google offers the GIS library to help you to quickly, and securely\nimplement an OAuth 2.0 client and optimize the user's authorization experience.\n\nChoosing an authorization flow\n------------------------------\n\nYou will need to choose one of two OAuth 2.0 authorization flows: implicit or\nauthorization code -- regardless if you decide to use the Google Identity\nServices JavaScript library or to create your own library.\n\nBoth flows result in an access token which can be used to call Google APIs.\n\nThe primary differences between the two flows are:\n\n- the number of user actions,\n- whether your app will call Google APIs without the user present,\n- if a backend platform is needed to host an endpoint and to store per-user refresh tokens for individual user accounts, and\n- higher or lower levels of user security.\n\nWhen comparing flows and evaluating your security requirements, a factor to\nconsider is that the level of user security varies depending on the scopes you\nchoose. For example, viewing calendar invites as read-only might be considered\nless risky than using a read/write scope to edit files in Drive.\n| **Key Point:** Authorization code flow is recommended because it provides a more secure flow.\n\nOAuth 2.0 flow comparison\n-------------------------\n\n|--------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|\n| | **Implicit flow** | **Authorization code flow** |\n| **User consent required** | For every token request, including replacing expired tokens. | Only for the first token request. |\n| **User must be present** | Yes | No, supports offline use. |\n| **User security** | Least | Most, has client authentication and avoids in-browser token handling risks. |\n| **Access token issued** | Yes | Yes |\n| **Refresh token issued** | No | Yes |\n| **Supported browser required** | Yes | Yes |\n| **Access token used to call Google APIs** | only from a web app running in the user's browser. | either from a server running on backend platform, or from a web app running in the user's browser. |\n| **Requires backend platform** | No | Yes, for endpoint hosting and storage. |\n| **Secure storage needed** | No | Yes, for refresh token storage. |\n| **Requires hosting of an authorization code endpoint** | No | Yes, to receive authorization codes from Google. |\n| **Access token expiration behavior** | A user gesture such as button press or clicking on a link is required to request and obtain a new, valid access token. | After an initial user request, your platform exchanges the stored refresh token to obtain a new, valid access token necessary to call Google APIs. |"]]
