OAuth 2.0 per le applicazioni web lato client

Questo documento spiega come implementare l'autorizzazione OAuth 2.0 per accedere alle API di Google da un'applicazione web JavaScript. OAuth 2.0 consente agli utenti di condividere dati specifici con un'applicazione, mantenendo privati i propri nomi utente, le password e altre informazioni. Ad esempio, un'applicazione può utilizzare OAuth 2.0 per ottenere l'autorizzazione degli utenti all'archiviazione dei file nei propri file di Google Drive.

Questo flusso OAuth 2.0 è chiamato flusso di autorizzazione implicita. È progettato per le applicazioni che accedono alle API solo quando l'utente è presente nell'applicazione. Queste applicazioni non sono in grado di memorizzare informazioni riservate.

In questo flusso, l'app apre un URL Google che utilizza i parametri di ricerca per identificare l'app e il tipo di accesso API richiesto dall'app. Puoi aprire l'URL nella finestra del browser o in un popup corrente. L'utente può autenticarsi con Google e concedere le autorizzazioni richieste. Dopodiché Google reindirizza l'utente all'app. Il reindirizzamento include un token di accesso, che l'app verifica e quindi utilizza per effettuare richieste API.

Libreria client delle API di Google e servizi di identità Google

Se utilizzi la libreria client delle API di Google per JavaScript per effettuare chiamate autorizzate a Google, devi utilizzare la libreria JavaScript di Servizi di identità Google per gestire il flusso OAuth 2.0. Consulta il modello di token dei servizi di identità Google, che si basa sul flusso di concessione implicita di OAuth 2.0.

Nota: date le implicazioni di sicurezza relative alla corretta implementazione dell'implementazione, ti invitiamo vivamente a utilizzare le librerie OAuth 2.0, come il modello di token dei servizi di identità Google, quando interagisci con gli endpoint OAuth 2.0 di Google. Una best practice consiste nell'utilizzare un codice ben debug eseguito da altri e che ti aiuterà a proteggere te e i tuoi utenti.

Il resto della pagina descrive come interagire direttamente con gli endpoint OAuth 2.0 di Google senza usare alcuna libreria OAuth 2.0.

Prerequisiti

Abilita le API per il tuo progetto

Qualsiasi applicazione che chiami le API di Google deve abilitarle nel API Console.

Per abilitare un'API per il tuo progetto:

1. Open the API Library in Google API Console.
2. If prompted, select a project, or create a new one.
3. L'elenco API Library elenca tutte le API disponibili, raggruppate per famiglia di prodotti e popolarità. Se l'API che vuoi attivare non è visibile nell'elenco, utilizza la ricerca per trovarla o fai clic su Visualizza tutto nella famiglia di prodotti a cui appartiene.
4. Seleziona l'API che vuoi abilitare, quindi fai clic sul pulsante Abilita.
5. If prompted, enable billing.
6. If prompted, read and accept the API's Terms of Service.

Crea credenziali di autorizzazione

Qualsiasi applicazione che utilizzi OAuth 2.0 per accedere alle API di Google deve disporre di credenziali di autorizzazione che identificano l'applicazione sul server OAuth 2.0 di Google. I passaggi seguenti spiegano come creare le credenziali per il tuo progetto. Le applicazioni possono quindi utilizzare le credenziali per accedere alle API che hai abilitato per il progetto.

1. Go to the Credentials page.
2. Fai clic su Crea credenziali > ID client OAuth.
3. Seleziona il tipo di applicazione Applicazione web.
4. Compila il modulo. Le applicazioni che utilizzano JavaScript per effettuare richieste API autorizzate di Google devono specificare le origini JavaScript autorizzate. Le origini identificano i domini da cui la tua applicazione può inviare richieste al server OAuth 2.0. Queste origini devono ottemperare alle regole di convalida di Google.

Identificare gli ambiti di accesso

Gli ambiti consentono alla tua applicazione di richiedere solo l'accesso alle risorse necessarie, permettendo al contempo agli utenti di controllare la quantità di accesso da loro concessa all'applicazione. Pertanto, potrebbe esistere una relazione inversa tra il numero di ambiti richiesti e la probabilità di ottenere il consenso dell'utente.

Prima di iniziare l'implementazione dell'autorizzazione OAuth 2.0, ti consigliamo di identificare gli ambiti a cui la tua app avrà bisogno dell'autorizzazione per accedere.

Il documento Ambiti API OAuth 2.0 contiene un elenco completo di ambiti che puoi utilizzare per accedere alle API di Google.

Se la tua applicazione pubblica utilizza ambiti che consentono l'accesso a determinati dati utente, deve completare una procedura di verifica. Se sullo schermo viene visualizzata un'app non verificata durante il test della tua applicazione, devi inviare una richiesta di verifica per rimuoverla. Scopri di più sulle app non verificate e leggi le risposte alle domande frequenti sulla verifica delle app nel Centro assistenza.

Ottenere i token di accesso OAuth 2.0

I passaggi seguenti mostrano in che modo la tua applicazione interagisce con il server OAuth 2.0 di Google per ottenere il consenso dell'utente a eseguire una richiesta API per suo conto. L'applicazione deve avere tale consenso prima di poter eseguire una richiesta API di Google che richiede l'autorizzazione dell'utente.

Passaggio 1: reindirizza al server OAuth 2.0 di Google

Per richiedere l'autorizzazione ad accedere ai dati di un utente, reindirizza l'utente al server OAuth 2.0 di Google.

Endpoint OAuth 2.0

Genera un URL per richiedere l'accesso dall'endpoint OAuth 2.0 di Google all'indirizzo https://accounts.google.com/o/oauth2/v2/auth. Questo endpoint è accessibile tramite HTTPS; le connessioni HTTP semplici vengono rifiutate.

Il server di autorizzazione di Google supporta i seguenti parametri della stringa di query per le applicazioni del server web:

Parametri
client_id	Obbligatorio L'ID client della tua applicazione. Puoi trovare questo valore nel API Console Credentials page.
redirect_uri	Obbligatorio Determina dove il server API reindirizza l'utente dopo che quest'ultimo ha completato il flusso di autorizzazione. Il valore deve corrispondere esattamente a uno degli URI di reindirizzamento autorizzati per il client OAuth 2.0, configurato nel API Consoleclient Credentials page. Se questo valore non corrisponde a un URI di reindirizzamento autorizzato per l'elemento client_id fornito, riceverai un errore redirect_uri_mismatch. Tieni presente che tutti gli schemi http o https, le maiuscole e le barre ('/') devono corrispondere.
response_type	Obbligatorio Le applicazioni JavaScript devono impostare il valore del parametro su token. Questo valore indica al server di autorizzazione di Google di restituire il token di accesso come coppia name=value nell'identificatore di frammento dell'URI (#) a cui l'utente viene reindirizzato dopo il completamento del processo di autorizzazione.
scope	Obbligatorio Un elenco di ambiti delimitato da spazi che identificano le risorse a cui la tua applicazione potrebbe accedere per conto dell'utente. Questi valori indicano la schermata per il consenso che Google mostra all'utente. Gli ambiti consentono all'applicazione di richiedere l'accesso solo alle risorse necessarie e agli utenti di controllare la quantità di accesso concessa all'applicazione. Esiste quindi una relazione inversa tra il numero di ambiti richiesti e la probabilità di ottenere il consenso dell'utente. Ti consigliamo di richiedere l'accesso all'applicazione agli ambiti di autorizzazione nel contesto, se possibile. Richiedendo l'accesso ai dati utente nel contesto, tramite l'autorizzazione incrementale, aiuti gli utenti a comprendere più facilmente il motivo per cui la tua applicazione ha bisogno dell'accesso richiesto.
state	Consigliato Specifica qualsiasi valore di stringa utilizzato dall'applicazione per mantenere lo stato tra la richiesta di autorizzazione e la risposta del server di autorizzazione. Il server restituisce il valore esatto inviato come coppia name=value nell'identificatore di frammento URL (#) di redirect_uri dopo che l'utente dà il consenso o nega la richiesta di accesso dell'applicazione. Puoi utilizzare questo parametro per diverse finalità, ad esempio indirizzare l'utente alla risorsa corretta nella tua applicazione, inviare nonce e mitigare la falsificazione del sito cross-site. Poiché è possibile indovinare il tuo redirect_uri, l'utilizzo di un valore di state può aumentare la tua garanzia che una connessione in entrata sia il risultato di una richiesta di autenticazione. Se generi una stringa casuale o codifica l'hash di un cookie o di un altro valore che acquisisce lo stato del client, puoi convalidare la risposta per assicurarti inoltre che la richiesta e la risposta abbiano origine nello stesso browser, proteggendoti da attacchi come la cross-site request falsificazione. Consulta la documentazione di OpenID Connect per un esempio di come creare e confermare un token state.
include_granted_scopes	Facoltativo Consente alle applicazioni di utilizzare l'autorizzazione incrementale per richiedere l'accesso ad ambiti aggiuntivi nel contesto. Se imposti il valore di questo parametro su true e viene concessa la richiesta di autorizzazione, il nuovo token di accesso coprirà anche tutti gli ambiti a cui l'utente ha precedentemente concesso l'accesso all'applicazione. Consulta la sezione Autorizzazione incrementale per alcuni esempi.
login_hint	Facoltativo Se la tua applicazione sa quale utente sta tentando di eseguire l'autenticazione, può utilizzare questo parametro per fornire un suggerimento al server di autenticazione Google. Il server utilizza il suggerimento per semplificare il flusso di accesso compilando il campo dell'email nel modulo di accesso o selezionando la sessione multi-accesso appropriata. Imposta il valore del parametro su un indirizzo email o un identificatore sub, che equivale all'ID Google dell'utente.
prompt	Facoltativo Un elenco di messaggi, sensibili alle maiuscole, che presentano la presenza dell'utente. Se non specifichi questo parametro, all'utente verrà richiesto solo il primo accesso al tuo progetto. Per saperne di più, consulta Richiesta di nuovo consenso. I valori possibili sono: none Non mostrare schermate di autenticazione o consenso. Non deve essere specificato con altri valori. consent Chiedere all'utente il consenso. select_account Chiedi all'utente di selezionare un account.

Esempio di reindirizzamento al server di autorizzazione di Google

Di seguito è riportato un URL di esempio, con interruzioni di riga e spazi per una migliore leggibilità.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly&
 include_granted_scopes=true&
 response_type=token&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

Dopo aver creato l'URL della richiesta, reindirizza l'utente all'URL.

Codice di esempio JavaScript

Il seguente snippet JavaScript mostra come avviare il flusso di autorizzazione in JavaScript senza utilizzare la libreria client delle API di Google per JavaScript. Poiché questo endpoint OAuth 2.0 non supporta la condivisione di risorse tra origini (CORS), lo snippet crea un modulo che apre la richiesta a tale endpoint.

/*
 * Create form to request access token from Google's OAuth 2.0 server.
 */
function oauthSignIn() {
  // Google's OAuth 2.0 endpoint for requesting an access token
  var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth';

  // Create <form> element to submit parameters to OAuth 2.0 endpoint.
  var form = document.createElement('form');
  form.setAttribute('method', 'GET'); // Send as a GET request.
  form.setAttribute('action', oauth2Endpoint);

  // Parameters to pass to OAuth 2.0 endpoint.
  var params = {'client_id': 'YOUR_CLIENT_ID',
                'redirect_uri': 'YOUR_REDIRECT_URI',
                'response_type': 'token',
                'scope': 'https://www.googleapis.com/auth/drive.metadata.readonly',
                'include_granted_scopes': 'true',
                'state': 'pass-through value'};

  // Add form parameters as hidden input values.
  for (var p in params) {
    var input = document.createElement('input');
    input.setAttribute('type', 'hidden');
    input.setAttribute('name', p);
    input.setAttribute('value', params[p]);
    form.appendChild(input);
  }

  // Add form to page and submit it to open the OAuth 2.0 endpoint.
  document.body.appendChild(form);
  form.submit();
}

Passaggio 2: Google chiede all'utente il consenso

In questo passaggio, l'utente decide se concedere alla tua applicazione l'accesso richiesto. In questa fase, Google mostra una finestra per il consenso che mostra il nome della tua applicazione e i servizi API di Google a cui richiede l'autorizzazione per accedere con le credenziali di autorizzazione dell'utente e un riepilogo degli ambiti da concedere. L'utente può quindi acconsentire alla concessione dell'accesso a uno o più ambiti richiesti dall'applicazione o rifiutare la richiesta.

In questa fase l'applicazione non deve fare nulla mentre attende la risposta dal server OAuth 2.0 di Google per indicare se è stato concesso alcun accesso. Questa risposta è spiegata nel passaggio successivo.

Errori

Nelle richieste all'endpoint di autorizzazione OAuth 2.0 di Google potrebbero essere visualizzati messaggi di errore rivolti agli utenti anziché i flussi di autenticazione e autorizzazione previsti. Di seguito sono elencati i codici di errore più comuni e le relative soluzioni.

admin_policy_enforced

L'Account Google non è in grado di autorizzare uno o più ambiti richiesti a causa delle norme dell'amministratore di Google Workspace. Per ulteriori informazioni su come un amministratore può limitare l'accesso a tutti gli ambiti o ad ambiti sensibili e con restrizioni, finché non verrà esplicitamente concesso l'accesso al tuo ID client OAuth, consulta l'articolo del Centro assistenza per amministratori di Google Workspace Controllare quali app di terze parti e interne possono accedere ai dati di Google Workspace.

disallowed_useragent

L'endpoint di autorizzazione viene visualizzato all'interno di uno user agent incorporato non consentito dalle norme OAuth 2.0 di Google.

Android

Gli sviluppatori Android potrebbero ricevere questo messaggio di errore quando aprono le richieste di autorizzazione in android.webkit.WebView. Gli sviluppatori dovrebbero invece utilizzare le librerie Android come Accedi con Google per Android o AppAuth per Android di Fondazione.

Gli sviluppatori web potrebbero riscontrare questo errore quando un'app per Android apre un link web generale in uno user agent incorporato e un utente accede all'endpoint di autorizzazione OAuth 2.0 di Google dal tuo sito. Gli sviluppatori devono consentire l'apertura dei link generali nel gestore di link predefinito del sistema operativo, che include sia i gestori di link per app Android sia l'app del browser predefinita. È supportata anche la libreria schede personalizzate Android.

iOS

Gli sviluppatori iOS e macOS potrebbero riscontrare questo errore quando aprono le richieste di autorizzazione in WKWebView. Gli sviluppatori dovrebbero invece utilizzare le librerie iOS come Accedi con Google per iOS o OpenID Foundation per AppAuth per iOS.

Gli sviluppatori web potrebbero riscontrare questo errore quando un'app per iOS o macOS apre un link web generale in uno user agent incorporato e un utente accede all'endpoint di autorizzazione OAuth 2.0 di Google dal tuo sito. Gli sviluppatori devono consentire l'apertura di link generali nel gestore di link predefinito del sistema operativo, che include sia i gestori di link universali sia l'app del browser predefinita. Anche la libreria SFSafariViewController è un'opzione supportata.

org_internal

L'ID client OAuth nella richiesta fa parte di un progetto che limita l'accesso agli Account Google in una organizzazione Google Cloud specifica. Per saperne di più su questa opzione di configurazione, consulta la sezione Tipo di utente nell'articolo del Centro assistenza Configurare la schermata di consenso OAuth.

invalid_client

L'origine da cui è stata effettuata la richiesta non è autorizzata per questo client. Consulta origin_mismatch.

invalid_grant

Quando utilizzi l'autorizzazione incrementale, il token potrebbe essere scaduto o essere stato invalidato. Autentica di nuovo l'utente e richiedi il consenso dell'utente per ottenere nuovi token. Se continui a visualizzare questo errore, assicurati che l'applicazione sia stata configurata correttamente e di utilizzare i token e i parametri corretti nella richiesta. In caso contrario, l'account utente potrebbe essere stato eliminato o disattivato.

origin_mismatch

Lo schema, il dominio e/o la porta del codice JavaScript che ha prodotto la richiesta di autorizzazione potrebbero non corrispondere a un URI di origine JavaScript autorizzato registrato per l'ID client OAuth. Esamina le origini JavaScript autorizzate in Google API Console Credentials page.

redirect_uri_mismatch

Il valore redirect_uri trasmesso nella richiesta di autorizzazione non corrisponde a un URI di reindirizzamento autorizzato per l'ID client OAuth. Esamina gli URI di reindirizzamento autorizzati in Google API Console Credentials page.

Lo schema, il dominio e/o la porta del codice JavaScript che ha prodotto la richiesta di autorizzazione potrebbero non corrispondere a un URI di origine JavaScript autorizzato registrato per l'ID client OAuth. Esamina le origini JavaScript autorizzate in Google API Console Credentials page.

Il parametro redirect_uri può fare riferimento al flusso OAuth fuori banda che è stato deprecato e non è più supportato. Consulta la guida alla migrazione per aggiornare l'integrazione.

Passaggio 3: gestisci la risposta del server OAuth 2.0

Endpoint OAuth 2.0

Il server OAuth 2.0 invia una risposta al redirect_uri specificato nella richiesta di token di accesso.

Se l'utente approva la richiesta, la risposta contiene un token di accesso. Se l'utente non approva la richiesta, la risposta contiene un messaggio di errore. Il token di accesso o il messaggio di errore viene restituito nel frammento hash dell'URI di reindirizzamento, come mostrato di seguito:

• Una risposta del token di accesso:

  https://oauth2.example.com/callback#access_token=4/P7q7W91&token_type=Bearer&expires_in=3600

  Oltre al parametro access_token, la stringa di frammento contiene anche il parametro token_type, sempre impostato su Bearer, e il parametro expires_in, che specifica la durata del token, in secondi. Se il parametro state è stato specificato nella richiesta del token di accesso, anche il relativo valore è incluso nella risposta.

• Una risposta di errore:

  https://oauth2.example.com/callback#error=access_denied

Nota: l'applicazione deve ignorare gli eventuali campi aggiuntivi non riconosciuti inclusi nella stringa di query.

Esempio di risposta del server OAuth 2.0

Puoi testare questo flusso facendo clic sul seguente URL di esempio, che richiede l'accesso in sola lettura per visualizzare i metadati per i file su Google Drive:

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly&
 include_granted_scopes=true&
 response_type=token&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

Una volta completato il flusso OAuth 2.0, verrai reindirizzato a http://localhost/oauth2callback. L'URL restituirà un errore 404 NOT FOUND, a meno che la macchina locale non fornisca un file a quell'indirizzo. Il passaggio successivo fornisce ulteriori dettagli sulle informazioni restituite nell'URI quando l'utente viene reindirizzato alla tua applicazione.

Chiamata alle API di Google

Endpoint OAuth 2.0

Dopo che l'applicazione ha ottenuto un token di accesso, puoi utilizzarlo per effettuare chiamate a un'API di Google per conto di un determinato account utente se sono stati concessi gli ambiti di accesso richiesti dall'API. A tale scopo, includi il token di accesso in una richiesta all'API includendo un parametro di ricerca access_token o un valore dell'intestazione HTTP Authorization Bearer. Se possibile, è preferibile l'intestazione HTTP, perché le stringhe di query tendono a essere visibili nei log del server. Nella maggior parte dei casi puoi utilizzare una libreria client per configurare le chiamate alle API di Google (ad esempio, quando chiamate l'API Drive Files).

Puoi provare tutte le API di Google e visualizzarne gli ambiti nel Playground OAuth 2.0.

Esempi HTTP GET

Una chiamata all'endpoint drive.files (API Drive Files) che utilizza l'intestazione HTTP Authorization: Bearer potrebbe avere il seguente aspetto. Tieni presente che devi specificare il tuo token di accesso:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Ecco una chiamata alla stessa API per l'utente autenticato che utilizza il parametro della stringa di query access_token:

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

Esempi di curl

Puoi testare questi comandi con l'applicazione a riga di comando curl. Ecco un esempio che utilizza l'opzione di intestazione HTTP (opzione preferita):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

In alternativa, l'opzione del parametro della stringa di query:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Codice di esempio JavaScript

Lo snippet di codice riportato di seguito mostra come utilizzare CORS (Condivisione delle risorse multiorigine) per inviare una richiesta a un'API di Google. Questo esempio non utilizza la libreria client delle API di Google per JavaScript. Tuttavia, anche se non utilizzi la libreria client, la guida dell'assistenza CORS nella documentazione della libreria ti aiuterà a comprendere meglio queste richieste.

In questo snippet di codice, la variabile access_token rappresenta il token che hai ottenuto per effettuare richieste API per conto dell'utente autorizzato. L'esempio completo mostra come archiviare il token nella memoria locale del browser e recuperarlo quando si effettua una richiesta API.

var xhr = new XMLHttpRequest();
xhr.open('GET',
    'https://www.googleapis.com/drive/v3/about?fields=user&' +
    'access_token=' + params['access_token']);
xhr.onreadystatechange = function (e) {
  console.log(xhr.response);
};
xhr.send(null);

Completa l'esempio

Endpoint OAuth 2.0

Questo esempio di codice mostra come completare il flusso OAuth 2.0 in JavaScript senza utilizzare la libreria client delle API di Google per JavaScript. Il codice riguarda una pagina HTML che visualizza un pulsante per provare una richiesta API. Se fai clic sul pulsante, il codice controlla se nella pagina è stato archiviato un token di accesso all'API nello spazio di archiviazione locale del browser. In questo caso, esegue la richiesta API. In caso contrario, viene avviato il flusso OAuth 2.0.

Per il flusso OAuth 2.0, la pagina segue questi passaggi:

1. Indirizza l'utente al server OAuth 2.0 di Google, che richiede l'accesso all'ambito https://www.googleapis.com/auth/drive.metadata.readonly.
2. Dopo aver concesso (o negato) l'accesso a uno o più ambiti richiesti, l'utente viene reindirizzato alla pagina originale, che analizza il token di accesso dalla stringa dell'identificatore di frammento.

3. La pagina utilizza il token di accesso per effettuare la richiesta API di esempio.

   La richiesta API chiama il metodo about.get dell'API Drive per recuperare informazioni sull'account Google Drive dell'utente autorizzato.

4. Se la richiesta viene eseguita correttamente, la risposta API viene registrata nella console di debug del browser.

Puoi revocare l'accesso all'app tramite la pagina Autorizzazioni del tuo Account Google. L'app verrà elencata come Demo OAuth 2.0 per i documenti dell'API di Google.

Per eseguire questo codice in locale, devi impostare i valori delle variabili YOUR_CLIENT_ID e YOUR_REDIRECT_URI che corrispondono alle credenziali di autorizzazione. La variabile YOUR_REDIRECT_URI deve essere impostata sullo stesso URL in cui viene pubblicata la pagina. Il valore deve corrispondere esattamente a uno degli URI di reindirizzamento autorizzati per il client OAuth 2.0, configurato nel API Console Credentials page. Se questo valore non corrisponde a un URI autorizzato, verrà visualizzato un errore redirect_uri_mismatch. Per questa richiesta, il progetto deve anche aver abilitato l'API appropriata.

<html><head></head><body>
<script>
  var YOUR_CLIENT_ID = 'REPLACE_THIS_VALUE';
  var YOUR_REDIRECT_URI = 'REPLACE_THIS_VALUE';
  var fragmentString = location.hash.substring(1);

  // Parse query string to see if page request is coming from OAuth 2.0 server.
  var params = {};
  var regex = /([^&=]+)=([^&]*)/g, m;
  while (m = regex.exec(fragmentString)) {
    params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
  }
  if (Object.keys(params).length > 0) {
    localStorage.setItem('oauth2-test-params', JSON.stringify(params) );
    if (params['state'] && params['state'] == 'try_sample_request') {
      trySampleRequest();
    }
  }

  // If there's an access token, try an API request.
  // Otherwise, start OAuth 2.0 flow.
  function trySampleRequest() {
    var params = JSON.parse(localStorage.getItem('oauth2-test-params'));
    if (params && params['access_token']) {
      var xhr = new XMLHttpRequest();
      xhr.open('GET',
          'https://www.googleapis.com/drive/v3/about?fields=user&' +
          'access_token=' + params['access_token']);
      xhr.onreadystatechange = function (e) {
        if (xhr.readyState === 4 && xhr.status === 200) {
          console.log(xhr.response);
        } else if (xhr.readyState === 4 && xhr.status === 401) {
          // Token invalid, so prompt for user permission.
          oauth2SignIn();
        }
      };
      xhr.send(null);
    } else {
      oauth2SignIn();
    }
  }

  /*
   * Create form to request access token from Google's OAuth 2.0 server.
   */
  function oauth2SignIn() {
    // Google's OAuth 2.0 endpoint for requesting an access token
    var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth';

    // Create element to open OAuth 2.0 endpoint in new window.
    var form = document.createElement('form');
    form.setAttribute('method', 'GET'); // Send as a GET request.
    form.setAttribute('action', oauth2Endpoint);

    // Parameters to pass to OAuth 2.0 endpoint.
    var params = {'client_id': YOUR_CLIENT_ID,
                  'redirect_uri': YOUR_REDIRECT_URI,
                  'scope': 'https://www.googleapis.com/auth/drive.metadata.readonly',
                  'state': 'try_sample_request',
                  'include_granted_scopes': 'true',
                  'response_type': 'token'};

    // Add form parameters as hidden input values.
    for (var p in params) {
      var input = document.createElement('input');
      input.setAttribute('type', 'hidden');
      input.setAttribute('name', p);
      input.setAttribute('value', params[p]);
      form.appendChild(input);
    }

    // Add form to page and submit it to open the OAuth 2.0 endpoint.
    document.body.appendChild(form);
    form.submit();
  }
</script>

<button onclick="trySampleRequest();">Try sample request</button>
</body></html>

Regole di convalida dell'origine JavaScript

Google applica le seguenti regole di convalida alle origini JavaScript per aiutare gli sviluppatori a proteggere le loro applicazioni. Le origini JavaScript devono rispettare queste regole. Consulta la sezione 3986 della RFC 3 per la definizione di dominio, host e schema, menzionata di seguito.

Regole di convalida
Schema	Le origini JavaScript devono utilizzare lo schema HTTPS, non HTTP semplice. Gli URI Localhost (inclusi gli URI degli indirizzi IP localhost) sono esenti da questa regola.
Host	Gli host non possono essere indirizzi IP non elaborati. Gli indirizzi IP Localhost sono esenti da questa regola.
Dominio	I domini di primo livello host (domini di primo livello) devono appartenere all'elenco dei suffissi pubblici. I domini host non possono essere “googleusercontent.com”. Le origini JavaScript non possono contenere domini abbreviati di URL (ad es. goo.gl), a meno che l'app non sia proprietaria del dominio.
Informazioni utente	Le origini JavaScript non possono contenere il sottocomponente userinfo.
Percorso	Le origini JavaScript non possono contenere il componente del percorso.
Query	Le origini JavaScript non possono contenere il componente della query.
Frammento	Le origini JavaScript non possono contenere il componente frammento.
Caratteri	Le origini JavaScript non possono contenere determinati caratteri, tra cui: Caratteri jolly ('*') Caratteri ASCII non stampabili Codifiche percentuale non valide (qualsiasi codifica percentuale che non segue la forma di codifica URL di un segno percentuale seguito da due cifre esadecimali) Caratteri null (un carattere NULL codificato, ad es. %00, %C0%80)

Autorizzazione incrementale

Nel protocollo OAuth 2.0, l'app richiede l'autorizzazione ad accedere alle risorse identificate dagli ambiti. È considerata una best practice per l'esperienza utente richiedere l'autorizzazione per le risorse quando ne hai bisogno. Per abilitare tale pratica, il server di autorizzazione di Google supporta l'autorizzazione incrementale. Questa funzionalità consente di richiedere ambiti in base alle esigenze e, se l'utente concede l'autorizzazione per il nuovo ambito, restituisce un codice di autorizzazione che può essere scambiato con un token contenente tutti gli ambiti concessi dall'utente al progetto.

Ad esempio, un'app che consente agli utenti di campionare le tracce musicali e di creare mix potrebbe richiedere al momento dell'accesso pochissime risorse, ad esempio il nome della persona che esegue l'accesso. Tuttavia, il salvataggio di un mix completato richiede l'accesso a Google Drive. La maggior parte delle persone lo trova naturale se gli viene richiesto solo l'accesso a Google Drive nel momento in cui l'app ne ha effettivamente bisogno.

In questo caso, al momento dell'accesso l'app potrebbe richiedere gli ambiti openid e profile per eseguire l'accesso di base e poi richiedere l'ambito https://www.googleapis.com/auth/drive.file al momento della prima richiesta per salvare un mix.

Le seguenti regole si applicano a un token di accesso ottenuto da un'autorizzazione incrementale:

• Il token può essere utilizzato per accedere alle risorse corrispondenti a uno qualsiasi degli ambiti inseriti nella nuova autorizzazione combinata.
• Quando utilizzi il token di aggiornamento per l'autorizzazione combinata per ottenere un token di accesso, il token di accesso rappresenta l'autorizzazione combinata e può essere utilizzato per uno qualsiasi dei valori scope inclusi nella risposta.
• L'autorizzazione combinata include tutti gli ambiti concessi dall'utente al progetto API anche se le concessioni sono state richieste da client diversi. Ad esempio, se un utente ha concesso l'accesso a un ambito utilizzando il client desktop di un'applicazione e poi ha concesso un altro ambito alla stessa applicazione tramite un client mobile, l'autorizzazione combinata includerà entrambi gli ambiti.
• Se revochi un token che rappresenta un'autorizzazione combinata, l'accesso a tutti gli ambiti di tale autorizzazione per conto dell'utente associato viene revocato contemporaneamente.

Attenzione: se scegli di includere gli ambiti concessi, verranno aggiunti automaticamente alla richiesta di autorizzazione gli ambiti concessi in precedenza dall'utente. Se la tua app non è attualmente approvata per richiedere tutti gli ambiti che potrebbero essere restituiti nella risposta, potrebbe essere visualizzata una pagina di avviso o di errore. Per ulteriori informazioni, consulta la sezione App non verificate.

Gli esempi di codice riportati di seguito mostrano come aggiungere ambiti a un token di accesso esistente. Questo approccio consente all'app di evitare di dover gestire più token di accesso.

Endpoint OAuth 2.0

Per aggiungere ambiti a un token di accesso esistente, includi il parametro include_granted_scopes nella richiesta al server OAuth 2.0 di Google.

Il seguente snippet di codice illustra come farlo. Lo snippet presuppone che tu abbia archiviato gli ambiti per i quali il token di accesso è valido nello spazio di archiviazione locale del browser. Il codice dell'esempio completo archivia un elenco di ambiti per cui il token di accesso è valido impostando la proprietà oauth2-test-params.scope nello spazio di archiviazione locale del browser.

Lo snippet confronta gli ambiti per i quali il token di accesso è valido per l'ambito che vuoi utilizzare per una determinata query. Se il token di accesso non copre questo ambito, viene avviato il flusso OAuth 2.0. In questo caso, la funzione oauth2SignIn è uguale a quella fornita nel passaggio 2 (e viene fornita in seguito nell'esempio completo).

var SCOPE = 'https://www.googleapis.com/auth/drive.metadata.readonly';
var params = JSON.parse(localStorage.getItem('oauth2-test-params'));

var current_scope_granted = false;
if (params.hasOwnProperty('scope')) {
  var scopes = params['scope'].split(' ');
  for (var s = 0; s < scopes.length; s++) {
    if (SCOPE == scopes[s]) {
      current_scope_granted = true;
    }
  }
}

if (!current_scope_granted) {
  oauth2SignIn(); // This function is defined elsewhere in this document.
} else {
  // Since you already have access, you can proceed with the API request.
}

Revoca di un token

In alcuni casi un utente potrebbe voler revocare l'accesso concesso a un'applicazione. Un utente può revocare l'accesso dalle Impostazioni account. Per saperne di più, consulta la sezione Rimuovere l'accesso di siti e app ai siti di terze parti e alle app che hanno accesso al tuo account.

Inoltre, un'applicazione può revocare in modo programmatico l'accesso che gli è stato concesso. La revoca della pubblicità programmatica è importante nei casi in cui un utente annulla l'iscrizione, rimuove un'applicazione o le risorse API richieste da un'app sono cambiate in modo significativo. In altre parole, parte del processo di rimozione può includere una richiesta API per garantire che le autorizzazioni precedentemente concesse all'applicazione vengano rimosse.

Endpoint OAuth 2.0

Per revocare in modo programmatico un token, la tua applicazione invia una richiesta a https://oauth2.googleapis.com/revoke e include il token come parametro:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

Il token può essere un token di accesso o un token di aggiornamento. Se il token è un token di accesso e ha un token di aggiornamento corrispondente, verrà revocato anche il token di aggiornamento.

Nota: l'endpoint OAuth 2.0 di Google per la revoca dei token supporta il protocollo JSONP e l'invio di moduli. Non supporta la condivisione delle risorse tra origini (CORS).

Se la revoca è stata elaborata correttamente, il codice di stato HTTP della risposta è 200. Per le condizioni di errore, viene restituito un codice di stato HTTP 400 e un codice di errore.

Il seguente snippet JavaScript mostra come revocare un token in JavaScript senza utilizzare la libreria client delle API di Google per JavaScript. Poiché l'endpoint OAuth 2.0 di Google per la revoca dei token non supporta la condivisione delle risorse tra origini (CORS), il codice crea un modulo e invia il modulo all'endpoint anziché utilizzare il metodo XMLHttpRequest() per pubblicare la richiesta.

function revokeAccess(accessToken) {
  // Google's OAuth 2.0 endpoint for revoking access tokens.
  var revokeTokenEndpoint = 'https://oauth2.googleapis.com/revoke';

  // Create <form> element to use to POST data to the OAuth 2.0 endpoint.
  var form = document.createElement('form');
  form.setAttribute('method', 'post');
  form.setAttribute('action', revokeTokenEndpoint);

  // Add access token to the form so it is set as value of 'token' parameter.
  // This corresponds to the sample curl request, where the URL is:
  //      https://oauth2.googleapis.com/revoke?token={token}
  var tokenField = document.createElement('input');
  tokenField.setAttribute('type', 'hidden');
  tokenField.setAttribute('name', 'token');
  tokenField.setAttribute('value', accessToken);
  form.appendChild(tokenField);

  // Add form to page and submit it to actually revoke the token.
  document.body.appendChild(form);
  form.submit();
}

Nota: dopo aver risposto correttamente alla revoca, potrebbe essere necessario attendere un po' di tempo prima che la revoca venga applicata.