Utilizzo di OAuth 2.0 per le applicazioni web lato client

Questo documento spiega come implementare l'autorizzazione OAuth 2.0 per accedere all'API YouTube Data 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 a recuperare i dati di YouTube di un canale.

Questo flusso OAuth 2.0 è chiamato flusso di concessione 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 di Google che utilizza i parametri di query per identificare l'app e il tipo di accesso all'API richiesto dall'app. Puoi aprire l'URL nella finestra del browser corrente o in un popup. L'utente può autenticarsi con Google e concedere le autorizzazioni richieste. Google reindirizza quindi l'utente alla tua app. Il reindirizzamento include un token di accesso, che la tua app verifica e poi utilizza per effettuare richieste all'API.

Libreria client delle API di Google e Google Identity Services

Se utilizzi la libreria client delle API di Google per JavaScript per effettuare chiamate autorizzate a Google, devi utilizzare la libreria JavaScript Google Identity Services per gestire il flusso OAuth 2.0. Consulta il modello di token di Google Identity Services, basato sul flusso di concessione implicita di OAuth 2.0.

Prerequisiti

Abilita le API per il tuo progetto

Qualsiasi applicazione che chiama le API di Google deve attivarle in API Console.

Per attivare 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. Utilizza la pagina Libreria per trovare e attivare l'API di dati di YouTube. Trova le altre API che verranno utilizzate dalla tua applicazione e abilitale.

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 per il server OAuth 2.0 di Google. I passaggi riportati di seguito spiegano come creare le credenziali per il progetto. Le applicazioni possono quindi utilizzare le credenziali per accedere alle API che hai attivato 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 autorizzate all'API 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 rispettare le regole di convalida di Google.

Identificare gli ambiti di accesso

Gli ambiti consentono alla tua applicazione di richiedere l'accesso solo alle risorse di cui ha bisogno, consentendo inoltre agli utenti di controllare la quantità di accesso concessa alla tua applicazione. Pertanto, potrebbe esserci una relazione inversa tra il numero di ambiti richiesti e la probabilità di ottenere il consenso dell'utente.

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

L'API YouTube Data v3 utilizza i seguenti ambiti:

Mirini con ingrandimento
https://www.googleapis.com/auth/youtubeGestisci il tuo account YouTube
https://www.googleapis.com/auth/youtube.channel-memberships.creatorVisualizzare un elenco dei tuoi attuali membri attivi del canale, il loro livello corrente e quando sono diventati membri
https://www.googleapis.com/auth/youtube.force-sslVisualizzare, modificare ed eliminare definitivamente video, valutazioni, commenti e sottotitoli di YouTube
https://www.googleapis.com/auth/youtube.readonlyVisualizza il tuo account YouTube
https://www.googleapis.com/auth/youtube.uploadGestisci i tuoi video su YouTube
https://www.googleapis.com/auth/youtubepartnerVisualizzare e gestire le risorse e i relativi contenuti su YouTube
https://www.googleapis.com/auth/youtubepartner-channel-auditVisualizzare le informazioni private del tuo canale YouTube pertinenti durante la procedura di revisione con un partner di YouTube

Il documento 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 che seguono mostrano come 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 disporre di questo consenso prima di poter eseguire una richiesta all'API Google che richiede l'autorizzazione dell'utente.

Passaggio 1: reindirizza al server OAuth 2.0 di Google

Per richiedere l'autorizzazione per accedere ai dati di un utente, reindirizzalo 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 non protette vengono rifiutate.

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

Parametri
client_id Obbligatorio

L'ID client della tua applicazione. Puoi trovare questo valore in API Console Credentials page.

redirect_uri Obbligatorio

Determina dove il server API reindirizza l'utente dopo che l'utente ha completato il flusso di autorizzazione. Il valore deve corrispondere esattamente a uno degli URI di reindirizzamento autorizzati per il client OAuth 2.0, che hai configurato in API Console Credentials pagedel client. Se questo valore non corrisponde a un URI di reindirizzamento autorizzato per il client_id fornito, verrà visualizzato un errore redirect_uri_mismatch.

Tieni presente che lo schema, le maiuscole e la barra finale http o https ('/') 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 del frammento dell'URI (#) a cui l'utente viene reindirizzato dopo aver completato la procedura di autorizzazione.

scope Obbligatorio

Un elenco di ambiti delimitati da spazi che identificano le risorse a cui la tua applicazione potrebbe accedere per conto dell'utente. Questi valori vengono utilizzati nella schermata di consenso che Google mostra all'utente.

Gli ambiti consentono alla tua applicazione di richiedere l'accesso solo alle risorse di cui ha bisogno, consentendo al contempo agli utenti di controllare la quantità di accesso che concedono alla tua applicazione. Pertanto, esiste una relazione inversa tra il numero di ambiti richiesti e la probabilità di ottenere il consenso dell'utente.

L'API YouTube Data v3 utilizza i seguenti ambiti:

Mirini con ingrandimento
https://www.googleapis.com/auth/youtubeGestisci il tuo account YouTube
https://www.googleapis.com/auth/youtube.channel-memberships.creatorVisualizzare un elenco dei tuoi attuali membri attivi del canale, il loro livello corrente e quando sono diventati membri
https://www.googleapis.com/auth/youtube.force-sslVisualizzare, modificare ed eliminare definitivamente video, valutazioni, commenti e sottotitoli di YouTube
https://www.googleapis.com/auth/youtube.readonlyVisualizza il tuo account YouTube
https://www.googleapis.com/auth/youtube.uploadGestisci i tuoi video su YouTube
https://www.googleapis.com/auth/youtubepartnerVisualizzare e gestire le risorse e i relativi contenuti su YouTube
https://www.googleapis.com/auth/youtubepartner-channel-auditVisualizzare le informazioni private del tuo canale YouTube pertinenti durante la procedura di revisione con un partner di YouTube

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

Ti consigliamo di richiedere all'applicazione di richiedere l'accesso agli ambiti di autorizzazione in contesto , se possibile. Se richiedi l'accesso ai dati utente nel contesto tramite autorizzazione incrementale, aiuterai gli utenti a comprendere più facilmente perché 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 che invii come coppia name=value nell' identificatore di frammenti di URL (#) del redirect_uri dopo che l'utente ha acconsentito o negato la richiesta di accesso della tua applicazione.

Puoi utilizzare questo parametro per diversi scopi, ad esempio per indirizzare l'utente alla risorsa corretta nella tua applicazione, inviare nonce e mitigare la contraffazione delle richieste cross-site. Poiché il tuo redirect_uri può essere dedotto, l'utilizzo di un valore state può aumentare la certezza che una connessione in entrata sia il risultato di una richiesta di autenticazione. Se generi una stringa casuale o codifichi 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 avuto origine nello stesso browser, offrendo protezione contro attacchi come la contraffazione di richieste cross-site. 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 a ambiti aggiuntivi nel contesto. Se imposti il valore di questo parametro su true e la richiesta di autorizzazione viene concessa, il nuovo token di accesso coprirà anche tutti gli ambiti a cui l'utente ha precedentemente concesso l'accesso all'applicazione. Per esempi, consulta la sezione Autorizzazione incrementale.

login_hint Facoltativo

Se la tua applicazione sa quale utente sta tentando di autenticarsi, può utilizzare questo parametro per fornire un suggerimento al server di autenticazione di Google. Il server utilizza il suggerimento per semplificare il flusso di accesso precompilando il campo email nel modulo di accesso o selezionando la sessione di 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 prompt da presentare all'utente, separati da spazi e sensibili alle maiuscole. Se non specifichi questo parametro, all'utente verrà chiesto di confermare solo la prima volta che il progetto richiede l'accesso. Per saperne di più, consulta la sezione Richiesta di un nuovo consenso.

I valori possibili sono:

none Non mostrare schermate di autenticazione o consenso. Non deve essere specificato con 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 la leggibilità. L'URL richiede accesso a un ambito che consente di recuperare i dati di YouTube dell'utente. Utilizza l'autorizzazione incrementale (include_granted_scopes=true) per garantire che il nuovo token di accesso copra tutti gli ambiti a cui l'utente ha concesso in precedenza l'accesso all'applicazione. Nell'esempio sono impostati anche diversi altri parametri.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl&
 include_granted_scopes=true&
 response_type=token&
 state=state_parameter_passthrough_value&
 redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback&
 client_id=client_id

Dopo aver creato l'URL della richiesta, reindirizza l'utente a questo 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 delle risorse tra origini (CORS), lo snippet crea un modulo 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/youtube.force-ssl https://www.googleapis.com/auth/calendar.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 all'applicazione l'accesso richiesto. A questo punto, Google mostra una finestra di consenso che mostra il nome dell'applicazione e i servizi dell'API di Google a cui sta richiedendo l'autorizzazione ad accedere con le credenziali di autorizzazione dell'utente e un riepilogo degli ambiti di accesso da concedere. L'utente può quindi acconsentire a concedere l'accesso a uno o più ambiti richiesti dalla tua applicazione o rifiutare la richiesta.

In questa fase l'applicazione non deve fare nulla mentre attende la risposta del server OAuth 2.0 di Google che indica se è stato concesso l'accesso. Questa risposta è spiegata nel 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. Di seguito sono riportati i codici di errore comuni e le soluzioni suggerite.

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. Consulta l'articolo del Centro assistenza Google Workspace Specificare quali app di terze parti e interne possono accedere ai dati di Google Workspace per saperne di più su come un amministratore può limitare l'accesso a tutti gli ambiti o agli ambiti sensibili e con limitazioni finché l'accesso non viene concesso esplicitamente al tuo ID cliente OAuth.

disallowed_useragent

L'endpoint di autorizzazione viene visualizzato all'interno di un user-agent incorporato non consentito dalle Norme di OAuth 2.0 di Google.

Android

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

Gli sviluppatori web potrebbero riscontrare questo errore quando un'app per Android apre un link web generico in un agente utente 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 generici nel gestore dei link predefinito del sistema operativo, che include sia i gestori di Android App Links sia l'app browser predefinita. Anche la libreria Android Custom Tabs è 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 utilizzare librerie per iOS come Google Sign-In per iOS o AppAuth per iOS di OpenID Foundation.

Gli sviluppatori web potrebbero riscontrare questo errore quando un'app per iOS o macOS apre un link web generico in un agente utente 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 generici nel gestore dei link predefinito del sistema operativo, che include sia i gestori dei link universali sia l'app del browser predefinito. 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 dell'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 non essere più valido. Autentica di nuovo l'utente e chiedi il suo consenso per ottenere nuovi token. Se continui a visualizzare questo errore, assicurati che l'applicazione sia stata configurata correttamente e che tu stia utilizzando 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 generato la richiesta di autorizzazione potrebbero non corrispondere a un URI di origine JavaScript autorizzato registrato per l'ID client OAuth. Controlla le origini JavaScript autorizzate in Google API Console Credentials page.

redirect_uri_mismatch

Il valore redirect_uri passato 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 generato 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 potrebbe fare riferimento al flusso OAuth out-of-band (OOB) che è stato ritirato e non è più supportato. Consulta la guida alla migrazione per aggiornare l'integrazione.

invalid_request

Si è verificato un problema con la richiesta che hai inviato. Ciò potrebbe essere dovuto a diversi motivi:

  • La richiesta non è stata formattata correttamente
  • Nella richiesta mancavano i parametri obbligatori
  • La richiesta utilizza un metodo di autorizzazione non supportato da Google. Verificare che l'integrazione OAuth utilizzi 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 all'redirect_uri specificato nella richiesta del 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 di 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 del frammento contiene anche 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 dell'token di accesso, il relativo valore è incluso anche 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 in Google Drive e accesso di sola lettura per visualizzare gli eventi di Google Calendar:

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl&
 include_granted_scopes=true&
 response_type=token&
 state=state_parameter_passthrough_value&
 redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback&
 client_id=client_id

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

Passaggio 4: controlla quali ambiti sono stati concessi dagli utenti

Quando richiedi più ambiti contemporaneamente, gli utenti potrebbero non concedere tutti gli ambiti richiesti dalla tua app. L'app deve sempre controllare quali ambiti sono stati concessi dall'utente e gestire eventuali rifiuti di ambiti disattivando le funzionalità pertinenti. Per ulteriori informazioni, consulta Come gestire le autorizzazioni granulari.

Endpoint OAuth 2.0

Per verificare se l'utente ha concesso alla tua applicazione l'accesso a un determinato ambito, esamina il campo scope nella risposta del token di accesso. Gli ambiti di accesso concessi dal token di accesso espressi come un elenco di stringhe sensibili alle maiuscole delimitate da spazi.

Ad esempio, la seguente risposta di esempio del token di accesso indica che l'utente ha concesso alla tua applicazione l'accesso alle autorizzazioni di sola lettura per le attività di Drive e gli eventi di Calendar:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/youtube.force-ssl https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

Chiamate 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 Google per conto di un determinato account utente se gli ambiti di accesso richiesti dall'API sono stati concessi. Per farlo, includi il token di accesso in una richiesta all'API includendo un parametro di query access_token o un valore Bearer dell'intestazione HTTP Authorization. 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 chiami l'API YouTube Live Streaming).

Tieni presente che l'API YouTube Live Streaming non supporta il flusso dell'account di servizio. Poiché non è possibile collegare un account di servizio a un account YouTube, i tentativi di autorizzare le richieste con questo flusso genereranno un errore NoLinkedYouTubeAccount.

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

Esempi di richieste GET HTTP

Una chiamata all'endpoint liveBroadcasts.list (l'API YouTube Live Streaming) che utilizza l'intestazione HTTP Authorization: Bearer potrebbe avere il seguente aspetto. Tieni presente che devi specificare il tuo token di accesso:

GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true 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/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

curl esempi

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true

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

curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

Codice di esempio JavaScript

Lo snippet di codice riportato di seguito mostra come utilizzare CORS (Cross-Origin Resource Sharing) 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 al supporto CORS nella documentazione della libreria potrebbe aiutarti 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 memorizzare il token nello spazio di archiviazione locale del browser e recuperarlo quando viene effettuata una richiesta API.

var xhr = new XMLHttpRequest();
xhr.open('GET',
    'https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id,snippet&mine=true' +
    '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 la libreria client delle API di Google per JavaScript. Il codice è per una pagina HTML che mostra un pulsante per provare una richiesta API. Se fai clic sul pulsante, il codice controlla se la pagina ha memorizzato un token di accesso API nello spazio di archiviazione locale del browser. In questo caso, esegue la richiesta API. In caso contrario, 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 agli ambiti https://www.googleapis.com/auth/youtube.force-ssl e https://www.googleapis.com/auth/calendar.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 del frammento.
  3. La pagina controlla gli ambiti a cui l'utente ha concesso l'accesso all'applicazione.
  4. Se l'utente ha concesso l'accesso agli scope() richiesti, la pagina utilizza il token di accesso per effettuare la richiesta API di esempio.

    Questa richiesta API chiama il liveBroadcasts.list metodo dell'API YouTube Data per recuperare un elenco di trasmissioni video per il canale YouTube dell'utente autorizzato.

  5. Se la richiesta viene eseguita correttamente, la risposta dell'API viene registrata nella console di debugging 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 la documentazione dell'API Google.

Per eseguire questo codice localmente, devi impostare i valori per le variabili YOUR_CLIENT_ID e YOUR_REDIRECT_URI corrispondenti alle tue 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 che hai configurato in API Console Credentials page. Se questo valore non corrisponde a un URI autorizzato, verrà visualizzato un errore redirect_uri_mismatch. Per questa richiesta, nel progetto deve essere stata anche attivata l'API appropriata.

<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']) { 
      // User authorized the request. Now, check which scopes were granted.
      if (params['scope'].includes('https://www.googleapis.com/auth/drive.metadata.readonly')) {
        // User authorized read-only Drive activity permission.
        // Calling the APIs, etc.
        var xhr = new XMLHttpRequest();
        xhr.open('GET',
          'https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id,snippet&mine=true' +
          '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 {
        // User didn't authorize read-only Drive activity permission.
        // Update UX and application accordingly
        console.log('User did not authorize read-only Drive activity permission.');
      }

      // Check if user authorized Calendar read permission.
      if (params['scope'].includes('https://www.googleapis.com/auth/calendar.readonly')) {
        // User authorized Calendar read permission.
        // Calling the APIs, etc.
        console.log('User authorized Calendar read permission.');
      }
      else {
        // User didn't authorize Calendar read permission.
        // Update UX and application accordingly
        console.log('User did not authorize Calendar read permission.');
      } 
    } 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/youtube.force-ssl https://www.googleapis.com/auth/calendar.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 a mantenere le loro applicazioni al sicuro. Le origini JavaScript devono rispettare queste regole. Consulta la sezione 3 del documento RFC 3986 per la definizione di dominio, host e schema riportata di seguito.

Regole di convalida
Schema

Le origini JavaScript devono utilizzare lo schema HTTPS, non il semplice HTTP. 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 TLD dell'host (Top Level Domains) devono appartenere all'elenco dei suffissi pubblici.
  • I domini host non possono essere “googleusercontent.com”.
  • Le origini JavaScript non possono contenere domini di URL abbreviati (ad es. goo.gl) a meno che il dominio non sia di proprietà dell'app.
  • Userinfo

    Le origini JavaScript non possono contenere il sottocomponente userinfo.

    Percorso

    Le origini JavaScript non possono contenere il componente path.

    Query

    Le origini JavaScript non possono contenere il componente query.

    Fragment

    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 percentuali non valide (qualsiasi codifica percentuale che non segue la forma di un segno di percentuale seguito da due cifre esadecimali della codifica dell'URL)
    • Caratteri null (un carattere NULL codificato, ad es. %00, %C0%80)

    Autorizzazione incrementale

    Nel protocollo OAuth 2.0, l'app richiede l'autorizzazione per accedere alle risorse, che sono identificate dagli ambiti. È considerata una best practice per l'esperienza utente richiedere l'autorizzazione per le risorse al momento del bisogno. Per abilitare questa pratica, il server di autorizzazione di Google supporta l'autorizzazione incrementale. Questa funzionalità ti consente di richiedere gli ambiti man mano che sono necessari e, se l'utente concede l'autorizzazione per il nuovo ambito, restituisce un codice di autorizzazione che può essere scambiato per un token contenente tutti gli ambiti concessi dall'utente al progetto.

    Ad esempio, supponiamo che un'app recuperi i dati del canale YouTube dell'utente autenticato e inoltre consenta all'utente di recuperare i dati di YouTube Analytics tramite un flusso speciale. In questo caso, al momento dell'accesso, l'app potrebbe richiedere l'accesso solo all'ambito https://www.googleapis.com/auth/youtube.force-ssl. Tuttavia, se l'utente ha provato ad accedere ai dati di Analytics per il proprio canale, l'app potrebbe anche richiedere l'accesso all'ambito https://www.googleapis.com/auth/yt-analytics.readonly.

    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 incorporati 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 qualsiasi valore scope incluso nella risposta.
    • L'autorizzazione combinata include tutti gli ambiti concessi dall'utente al progetto API anche 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 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 quell'autorizzazione per conto dell'utente associato viene revocato contemporaneamente.

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

    Endpoint OAuth 2.0

    In questo esempio, l'applicazione chiamante richiede l'accesso per recuperare i dati di YouTube dell'utente, oltre a qualsiasi altro accesso che l'utente ha già concesso all'applicazione.

    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 mostra come eseguire questa operazione. Lo snippet presuppone che tu abbia memorizzato gli ambiti per i quali il token di accesso è valido nello spazio di archiviazione locale del browser. Il codice dell'esempio completo memorizza un elenco di ambiti per i quali 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 con 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. Qui la funzione oauth2SignIn è la stessa fornita nel passaggio 2 (e fornita più avanti nell'esempio completo).

    var SCOPE = 'https://www.googleapis.com/auth/youtube.force-ssl';
    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.
    }

    Revocare un token

    In alcuni casi, un utente potrebbe voler revocare l'accesso concesso a un'applicazione. Un utente può revocare l'accesso visitando le Impostazioni account. Per saperne di più, consulta la sezione Rimuovere l'accesso di un sito o un'app del documento del Centro assistenza App e siti di terze parti con accesso al tuo account.

    È anche possibile che un'applicazione revochi in modo programmatico l'accesso che le è stato concesso. La revoca programmatica è importante nei casi in cui un utente annulla l'iscrizione, rimuove un'applicazione o le risorse dell'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 la rimozione delle autorizzazioni precedentemente concesse all'applicazione.

    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 ha un token di aggiornamento corrispondente, anche il token di aggiornamento verrà revocato.

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

    Lo snippet JavaScript seguente 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 lo invia 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();
    }

    Implementare la Protezione su più account

    Un ulteriore passaggio da seguire per proteggere gli account dei tuoi utenti è implementare la protezione tra account utilizzando il servizio di protezione tra account di Google. Questo servizio ti consente di iscriverti alle notifiche relative agli eventi di sicurezza che forniscono informazioni alla tua applicazione su modifiche importanti all'account utente. Puoi quindi utilizzare le informazioni per intervenire in base a come decidi di rispondere agli eventi.

    Ecco alcuni esempi di tipi di eventi inviati alla tua app dal Servizio di protezione tra 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

    Per ulteriori informazioni su come implementare la funzionalità Protezione su più account e per l'elenco completo degli eventi disponibili, consulta la pagina Proteggere gli account utente con la Protezione su più account .