OAuth 2.0 per applicazioni web lato client

Questo documento spiega come implementare l'autorizzazione di accesso OAuth 2.0 API di Google da un'applicazione web JavaScript. OAuth 2.0 consente agli utenti di condividono dati specifici con un'applicazione, conservando i relativi nomi utente, password le informazioni private. Ad esempio, un'applicazione può utilizzare OAuth 2.0 per ottenere l'autorizzazione consentire agli utenti di archiviare i file nei loro Google Drive.

Questo flusso OAuth 2.0 è chiamato flusso di concessione implicita. È progettata per applicazioni che accedono alle API solo quando l'utente è presente nell'applicazione. Questi non siano in grado di memorizzare informazioni riservate.

In questo flusso, l'app apre un URL di Google che utilizza parametri di query per identificarla e il tipo di accesso all'API richiesto dall'app. Puoi aprire l'URL nel browser corrente o un popup. L'utente può eseguire l'autenticazione con Google e concedere le autorizzazioni richieste. Google reindirizza l'utente alla tua app. Il reindirizzamento include un token di accesso, che l'app la verifica e poi la 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 Libreria JavaScript dei Servizi di identità Google per gestire il flusso OAuth 2.0. Consulta Google i servizi di identità token model, ovvero in base al flusso di concessione implicita di OAuth 2.0.

Prerequisiti

Abilita le API per il progetto

Qualsiasi applicazione che chiama le API di Google deve abilitare tali API 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. API Library elenca tutte le API disponibili, raggruppate per prodotto famiglia e popolarità. Se l'API che vuoi abilitare non è visibile nell'elenco, utilizza la ricerca per trovarlo o fare clic su Visualizza tutto nella famiglia di prodotti a cui appartiene.
  4. Seleziona l'API da abilitare e fai clic sul pulsante Abilita.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Crea le credenziali di autorizzazione

Qualsiasi applicazione che utilizza OAuth 2.0 per accedere alle API di Google deve disporre di credenziali di autorizzazione che identificano l'applicazione nel server OAuth 2.0 di Google. I passaggi seguenti spiegano come e 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 Web Application.
  4. Compila il modulo. Applicazioni che utilizzano JavaScript per effettuare richieste API di Google autorizzate devi specificare le origini JavaScript autorizzate. Le origini identificano i domini cui l'applicazione può inviare richieste al server OAuth 2.0. Queste origini devono rispettare alle regole di convalida di Google.

Identifica gli ambiti di accesso

Gli ambiti consentono all'applicazione di richiedere solo l'accesso alle risorse di cui ha bisogno, permettendo agli utenti di controllare la quantità di accesso che concedono alla tua applicazione. Pertanto, potrebbe essere una relazione inversa tra il numero di ambiti richiesti e la probabilità l'ottenimento del consenso degli utenti.

Prima di iniziare a implementare l'autorizzazione OAuth 2.0, ti consigliamo di identificare gli ambiti a cui la tua app dovrà avere l'autorizzazione ad accedere.

Il documento sugli ambiti API OAuth 2.0 contiene un elenco completo degli ambiti che potresti utilizzare per accedere alle API di Google.

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 di un utente a eseguire una richiesta API per suo conto. La tua applicazione deve avere Consenso prima che possa 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 a OAuth 2.0 di Google o server web.

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. e le connessioni HTTP semplici vengono rifiutate.

Il server di autorizzazione di Google supporta i seguenti parametri delle stringhe di query per il web applicazioni server:

Parametri
client_id Obbligatorio

L'ID client dell'applicazione. Puoi trovare questo valore nella sezione API Console Credentials page.

redirect_uri Obbligatorio

Determina dove il server API reindirizza l'utente dopo che quest'ultimo ha completato la flusso di autorizzazione. Il valore deve corrispondere esattamente a uno degli URI di reindirizzamento autorizzati per il client OAuth 2.0, che hai configurato nella API Console Credentials page. Se questo valore non corrisponde a URI di reindirizzamento autorizzato per il client_id fornito, riceverai un Errore redirect_uri_mismatch.

Tieni presente che lo schema http o https, le maiuscole e la barra finale ("/") devono corrispondere tutti.

response_type Obbligatorio

Le applicazioni JavaScript devono impostare il valore del parametro su token. Questo indica al server di autorizzazione Google di restituire il token di accesso come Coppia di name=value nell'identificatore di frammento dell'URI (#) a cui l'utente viene reindirizzato dopo aver completato la procedura di autorizzazione.

scope Obbligatorio

R delimitato da spazi l'elenco degli ambiti che identificano le risorse a cui la tua applicazione potrebbe accedere per conto dell'utente. Questi valori determinano la schermata di consenso che Google mostra al utente.

Gli ambiti consentono all'applicazione di richiedere l'accesso solo alle risorse di cui ha bisogno consentendo agli utenti di controllare il livello di accesso che concedono al tuo un'applicazione. Esiste quindi una relazione inversa tra il numero di ambiti richiesti e la probabilità di ottenere il consenso degli utenti.

Consigliamo alla tua applicazione di richiedere l'accesso agli ambiti di autorizzazione nel contesto ove possibile. Richiedendo l'accesso ai dati utente nel contesto, tramite autorizzazione incrementale, aiuti gli utenti a trovare più facilmente comprendi perché la tua applicazione ha bisogno dell'accesso richiesto.

state Consigliato

Specifica qualsiasi valore stringa che l'applicazione utilizza per mantenere lo stato tra e la risposta del server di autorizzazione. Il server restituisce il valore esatto che invii come coppia name=value nel Identificatore di frammento di URL (#) del redirect_uri dopo che l'utente ha dato il consenso o nega l'utilizzo dell'applicazione richiesta di accesso.

Puoi utilizzare questo parametro per diversi scopi, ad esempio per indirizzare l'utente alla sezione risorsa corretta nella tua applicazione, invio di nonce e mitigazione delle richieste tra siti contraffazione. Poiché redirect_uri può essere intuito, utilizzando un state può aumentare la tua garanzia che una connessione in entrata sia il risultato di un richiesta di autenticazione. Se generi una stringa casuale o codifichi l'hash di un cookie o un altro valore che acquisisce lo stato del client, puoi convalidare la risposta assicura inoltre che la richiesta e la risposta provengano dallo stesso browser che fornisce protezione contro attacchi richiesta tra siti falsificazione. Consulta le OpenID Connect documentazione 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 a nel contesto. Se imposti il valore di questo parametro su true e il valore richiesta di autorizzazione, il nuovo token di accesso coprirà anche qualsiasi ambito a cui l'utente ha concesso in precedenza l'accesso all'applicazione. Consulta le autorizzazione incrementale.

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 di Google. Il server utilizza il suggerimento semplificare il flusso di accesso precompilando il campo dell'email nel modulo di accesso o e seleziona la sessione con accesso multiplo appropriata.

Imposta il valore del parametro su un indirizzo email o un identificatore sub, che equivalente all'ID Google dell'utente.

prompt Facoltativo

Un elenco di richieste per presentare all'utente, delimitato da spazi, e sensibile alle maiuscole. In caso contrario questo parametro, all'utente verrà chiesto di inviare il messaggio solo la prima volta che richiede l'accesso. Vedi Richiesta di nuovo consenso per ulteriori informazioni.

I valori possibili sono:

none Non mostrare alcuna schermata di autenticazione o consenso. Non deve essere specificato con e altri valori.
consent Chiedi 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 a quest'ultimo.

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 OAuth L'endpoint 2.0 non supporta la condivisione delle risorse tra origini (CORS). Lo snippet crea un che apre la richiesta a quell'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 richiede il consenso all'utente

In questo passaggio, l'utente deciderà se concedere alla tua applicazione l'accesso richiesto. In questo momento di Google, Google mostra una finestra per il consenso che mostra il nome della tua applicazione e l'API di Google ai servizi a cui chiede l'autorizzazione ad accedere con le credenziali di autorizzazione dell'utente e un riepilogo degli ambiti di accesso da concedere. La l'utente può quindi concedere l'accesso a uno o più ambiti richiesti dalla tua applicazione oppure rifiutare la richiesta.

La tua richiesta non deve fare nulla in questa fase perché attende la risposta da Server OAuth 2.0 di Google che indica se è stato concesso un accesso. Questa risposta è spiegata in al passaggio successivo.

Errori

Le richieste all'endpoint di autorizzazione OAuth 2.0 di Google potrebbero mostrare messaggi di errore rivolti agli utenti anziché i flussi di autenticazione e autorizzazione previsti. Codici di errore comuni e suggerimenti le risoluzioni sono elencate di seguito.

admin_policy_enforced

L'Account Google non è in grado di autorizzare uno o più ambiti richiesti a causa dei criteri di amministratore di Google Workspace. Consulta l'articolo del Centro assistenza per amministratori di Google Workspace Controllare quali terze parti e quali le app interne accedono ai dati di Google Workspace per ulteriori informazioni su come un amministratore può limitare l'accesso a tutti gli ambiti o a tutti gli ambiti ambiti con restrizioni finché l'accesso non viene concesso esplicitamente al tuo ID client OAuth.

disallowed_useragent

L'endpoint di autorizzazione viene visualizzato all'interno di uno user agent incorporato non consentito dai Norme relative a OAuth 2.0.

Android

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

Gli sviluppatori web potrebbero riscontrare questo errore quando un'app per Android apre un link web generale in un uno user agent incorporato e un utente accede all'endpoint di autorizzazione OAuth 2.0 di Google nel tuo sito. Gli sviluppatori devono consentire l'apertura dei link generali nel gestore di link predefinito del sistema operativo, che include Link per app Android oppure l'app browser predefinita. La Schede personalizzate di Android è un'opzione supportata.

iOS

Gli sviluppatori iOS e macOS potrebbero riscontrare questo errore quando aprono le richieste di autorizzazione in WKWebView Gli sviluppatori dovrebbero invece usare le librerie iOS come Accedi con Google per iOS o OpenID Foundation 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 da nel tuo sito. Gli sviluppatori devono consentire l'apertura dei link generali nel gestore di link predefinito del sistema operativo, che include Link universali oppure l'app browser predefinita. La 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 un specifico Organizzazione Google Cloud. Per ulteriori informazioni su questa opzione di configurazione, consulta Tipo di utente nell'articolo del Centro assistenza Configurare la schermata per il 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 la sua validità è stata invalidata. Autentica di nuovo l'utente e richiedi il consenso dell'utente per ottenere nuovi token. Se continui di visualizzare questo errore, accertati che l'applicazione sia stata configurata correttamente e di avere utilizzando i token e i parametri corretti nella richiesta. In caso contrario, l'account utente potrebbe avere eliminati o disattivati.

origin_mismatch

Lo schema, il dominio e/o la porta del codice JavaScript che ha originato la richiesta di autorizzazione non possono corrispondono a un URI di origine JavaScript autorizzato registrato per l'ID client OAuth. Rivedi autorizzati Origini JavaScript 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 per l'ID client OAuth. Esamina gli URI di reindirizzamento autorizzati Google API Console Credentials page.

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

Il parametro redirect_uri può fare riferimento al flusso OAuth fuori banda (OOB) che ha è stata deprecata e non è più supportata. Consulta le guida alla migrazione per aggiornare e integrazione.

invalid_request

Si è verificato un problema nella richiesta che hai inviato. Ciò potrebbe essere dovuto a una serie di motivi:

  • La richiesta non è formattata correttamente
  • Nella richiesta mancano dei parametri obbligatori
  • La richiesta utilizza un metodo di autorizzazione non supportato da Google. Verifica il tuo OAuth l'integrazione utilizza un metodo di integrazione consigliato

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 in una 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 viene restituito un messaggio di errore 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, anche la stringa del frammento contiene il parametro token_type, che è 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 suo valore è incluso nella risposta.

  • Una risposta di errore:
    https://oauth2.example.com/callback#error=access_denied

Esempio di risposta del server OAuth 2.0

Puoi testare questo flusso facendo clic sul seguente URL di esempio, che richiede Accesso di sola lettura per visualizzare i metadati dei 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

Al termine del flusso OAuth 2.0, si aprirà la pagina http://localhost/oauth2callback. Tale URL produrrà 404 NOT FOUND errore, a meno che la tua macchina locale non pubblichi un file in questo indirizzo. Il passaggio successivo fornisce ulteriori dettagli sulle informazioni restituite nel URI quando l'utente viene reindirizzato alla tua applicazione.

Chiamata alle API di Google

Endpoint OAuth 2.0

Una volta che l'applicazione ha ottenuto un token di accesso, puoi utilizzarlo per effettuare chiamate a un API per conto di un utente account utente se sono stati concessi gli ambiti di accesso richiesti dall'API. Per farlo, includi il token di accesso in una richiesta all'API mediante l'inclusione di una query access_token o un valore Bearer dell'intestazione HTTP Authorization. Se possibile, è preferibile utilizzare l'intestazione HTTP, in quanto le stringhe di query tendono a essere visibili nei log del server. Nella maggior parte dei casi, casi puoi utilizzare una libreria client per configurare le chiamate alle API di Google (ad esempio, chiamata all'API Drive Files).

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

Esempi GET HTTP

Una chiamata al drive.files (l'API Drive Files) utilizzando il protocollo Authorization: Bearer potrebbe avere il seguente aspetto. Tieni presente che devi specificare un 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 utilizzando access_token parametro della stringa di query:

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

curl esempi

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

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

Oppure, 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 tra origini) 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 per il supporto per CORS nella documentazione della libreria è probabilmente utile per comprendere meglio queste richieste.

In questo snippet di codice, la variabile access_token rappresenta il token che hai per effettuare richieste API per conto dell'utente autorizzato. Il completamento esempio mostra come archiviare quel token nello spazio di archiviazione 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);

Esempio completo

Endpoint OAuth 2.0

Questo esempio di codice mostra come completare il flusso OAuth 2.0 in JavaScript senza utilizzare Libreria client delle API di Google per JavaScript. Il codice si riferisce a una pagina HTML in cui viene visualizzato un pulsante prova con una richiesta API. Se fai clic sul pulsante, il codice verifica se nella pagina è stato archiviato un Il token di accesso all'API nello spazio di archiviazione locale del browser. In questo caso, esegue la richiesta API. Altrimenti, avvia 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 al https://www.googleapis.com/auth/drive.metadata.readonly ambito.
  2. Dopo aver concesso (o negato) l'accesso a uno o più ambiti richiesti, l'utente viene reindirizzato la 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 le informazioni sull'account Google Drive dell'utente autorizzato.

  4. Se la richiesta viene eseguita correttamente, la risposta dell'API viene registrata nella fase di debug del browser Google Cloud.

Puoi revocare l'accesso all'app tramite il Autorizzazioni relative a: Account Google L'app sarà contrassegnata come OAuth 2.0 Demo for Google API Docs.

Per eseguire questo codice localmente, devi impostare i valori per YOUR_CLIENT_ID e YOUR_REDIRECT_URI variabili che corrispondono credenziali di autorizzazione. Variabile YOUR_REDIRECT_URI deve essere impostato sullo stesso URL su cui viene pubblicata la pagina. Il valore deve corrispondere esattamente a uno dei gli URI di reindirizzamento autorizzati per il client OAuth 2.0, che hai configurato nel API Console Credentials page. Se questo valore non corrisponde a un URI autorizzato, riceverai un redirect_uri_mismatch . Il progetto deve inoltre avere aver abilitato l'API appropriata per questa richiesta.

<html><head></head><body>
<script>
  var YOUR_CLIENT_ID = 'REPLACE_THIS_VALUE';
  var YOUR_REDIRECT_URI = 'REPLACE_THIS_VALUE';

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

      trySampleRequest();
    } else {
      console.log('State mismatch. Possible CSRF attack');
    }
  }

  // Function to generate a random state value
  function generateCryptoRandomState() {
    const randomValues = new Uint32Array(2);
    window.crypto.getRandomValues(randomValues);

    // Encode as UTF-8
    const utf8Encoder = new TextEncoder();
    const utf8Array = utf8Encoder.encode(
      String.fromCharCode.apply(null, randomValues)
    );

    // Base64 encode the UTF-8 data
    return btoa(String.fromCharCode.apply(null, utf8Array))
      .replace(/\+/g, '-')
      .replace(/\//g, '_')
      .replace(/=+$/, '');
  }

  // 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() {
    // create random state value and store in local storage
    var state = generateCryptoRandomState();
    localStorage.setItem('state', state);

    // 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': state,
                  '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 tengono al sicuro le loro applicazioni. Le tue origini JavaScript devono ottemperare a queste regole. Consulta la sezione 3 RFC 3986 per definizione di dominio, host e schema menzionata di seguito.

Regole di convalida
Schema

Le origini JavaScript devono utilizzare lo schema HTTPS, non il semplice HTTP. 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
  • Domini di primo livello host (Domini di primo livello) devono appartenere all'elenco di suffissi pubblici.
  • I domini host non possono essere “googleusercontent.com”.
  • Le origini JavaScript non possono contenere domini di abbreviazione 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 del frammento.

    Caratteri Le origini JavaScript non possono contenere determinati caratteri, tra cui:
    • Caratteri jolly ('*')
    • Caratteri ASCII non stampabili
    • Codifiche percentuali non valide (qualsiasi codifica percentuale che non segue la codifica dell'URL) un segno di percentuale seguito da due cifre esadecimali)
    • Caratteri null (un carattere NULL codificato, ad esempio %00, %C0%80)

    Autorizzazione incrementale

    Nel protocollo OAuth 2.0, la tua app richiede l'autorizzazione per accedere alle risorse, che sono identificati dagli ambiti. È considerata una best practice per l'esperienza utente richiedere l'autorizzazione risorse nel momento in cui ne hai bisogno. Per abilitare questa pratica, il server di autorizzazione di Google che supporta l'autorizzazione incrementale. Questa funzionalità ti consente di richiedere gli ambiti in base alle esigenze e, se l'utente concede l'autorizzazione per il nuovo ambito, restituisce un codice di autorizzazione che potrebbe essere scambiato con un token contenente tutti gli ambiti concessi dall'utente al progetto.

    Ad esempio, un'app che permette di campionare tracce musicali e creare mix potrebbe richiedere risorse al momento dell'accesso, magari altro che il nome della persona che effettua l'accesso. Tuttavia, salvare un mix completato richiede l'accesso al suo Google Drive. La maggior parte delle persone lo troverà naturale se agli è stato chiesto l'accesso a Google Drive solo nel momento in cui l'app ne aveva bisogno.

    In questo caso, al momento dell'accesso l'app potrebbe richiedere openid e profile ambiti per eseguire l'accesso di base e poi richiedere in un secondo momento https://www.googleapis.com/auth/drive.file ambito 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 qualsiasi ambito implementato nuova autorizzazione combinata.
    • Quando utilizzi il token di aggiornamento per l'autorizzazione combinata per ottenere un token di accesso, token di accesso rappresenta l'autorizzazione combinata e può essere utilizzato per qualsiasi scope valori inclusi nella risposta.
    • L'autorizzazione combinata include tutti gli ambiti concessi dall'utente al progetto API se le concessioni sono state richieste da clienti 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 allo stesso tramite un client mobile, l'autorizzazione combinata includerà entrambi gli ambiti.
    • Se revochi un token che rappresenta un'autorizzazione combinata, accedi a tutto di autorizzazione per conto dell'utente associato vengono revocati contemporaneamente.

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

    Endpoint OAuth 2.0

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

    Il seguente snippet di codice mostra 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. (La Nel codice di esempio completo è archiviato un elenco di ambiti per i quali il token di accesso sia valido impostando la proprietà oauth2-test-params.scope nel dominio locale storage.)

    Lo snippet confronta gli ambiti per i quali il token di accesso è valido con quelli che vuoi utilizzare per una determinata query. Se il token di accesso non copre tale ambito, viene avviato il flusso OAuth 2.0. In questo caso, la funzione oauth2SignIn è la stessa fornita in passaggio 2 (che verrà fornito più avanti nella esempio).

    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 decidere di revocare l'accesso concesso a un'applicazione. Un utente può revocare l'accesso visitando Impostazioni account. Consulta le Rimuovi sezione "Accesso a siti o app" della sezione Siti e app con accesso al tuo account documento di supporto per ulteriori informazioni.

    È anche possibile che un'applicazione revoca in modo programmatico l'accesso concesso. La revoca programmatica è importante nei casi in cui un utente annulla l'iscrizione, rimuove un 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 concessi all'applicazione vengono rimossi.

    Endpoint OAuth 2.0

    Per revocare un token in modo programmatico, l'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 presenta un corrispondente, verrà revocato anche il token di aggiornamento.

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

    Il seguente snippet JavaScript mostra come revocare un token in JavaScript senza utilizzare Libreria client delle API di Google per JavaScript. Poiché l'endpoint OAuth 2.0 di Google per la revoca non supporta la condivisione delle risorse tra origini (CORS), il codice crea un modulo e invia il modulo nell'endpoint anziché utilizzare il metodo XMLHttpRequest() per pubblicare 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();
    }

    Implementare la Protezione su più account

    Un ulteriore passaggio da seguire per proteggere i tuoi utenti che stanno implementando più account Protezione con l'utilizzo del servizio di protezione su più account di Google. Questo servizio ti consente iscriviti alle notifiche di eventi di sicurezza che forniscono informazioni alla tua applicazione su modifiche importanti all'account utente. Puoi quindi utilizzare le informazioni per intervenire in base al come decidi di rispondere agli eventi.

    Ecco alcuni esempi di tipi di eventi inviati alla tua app dal Servizio di protezione su più account di Google:

    • https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
    • https://schemas.openid.net/secevent/oauth/event-type/token-revoked
    • https://schemas.openid.net/secevent/risc/event-type/account-disabled

    Consulta le Proteggere gli account utente con la pagina Protezione su più account . per ulteriori informazioni su come implementare la Protezione su più account e per l'elenco completo degli eventi disponibili.