Questa pagina è stata tradotta dall'API Cloud Translation.

OAuth 2.0 per applicazioni TV e di dispositivi con input limitato

Questo documento spiega come implementare l'autorizzazione OAuth 2.0 per accedere all'API di dati di YouTube tramite applicazioni in esecuzione su dispositivi come TV, console per videogiochi e stampanti. In particolare, questo flusso è progettato per i dispositivi che non hanno accesso a un browser o che hanno capacità di input limitate.

OAuth 2.0 consente agli utenti di condividere dati specifici con un'applicazione, mantenendo privati i nomi utente, le password e altre informazioni. Ad esempio, un'applicazione TV potrebbe utilizzare OAuth 2.0 per ottenere l'autorizzazione a selezionare un file archiviato su Google Drive.

Poiché le applicazioni che utilizzano questo flusso vengono distribuite ai singoli dispositivi, si presume che le app non possano conservare i secret. Possono accedere alle API di Google mentre l'utente è presente nell'app o quando l'app è in esecuzione in background.

Alternative

Se stai scrivendo un'app per una piattaforma come Android, iOS, macOS, Linux o Windows (inclusa la piattaforma Universal Windows), che ha accesso al browser e funzionalità di input complete, utilizza il flusso OAuth 2.0 per applicazioni mobile e desktop. Dovresti utilizzare questo flusso anche se l'app è uno strumento a riga di comando senza un'interfaccia grafica.

Se vuoi accedere solo agli utenti con i loro Account Google e utilizzare il token ID JWT per ottenere informazioni di base del profilo utente, consulta la sezione Accesso su TV e dispositivi di input con limitazioni.

Prerequisiti

Abilita le API per il tuo progetto

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

Per abilitare un'API per il tuo progetto:

Open the API Library in Google API Console.
If prompted, select a project, or create a new one.
Utilizza la pagina Raccolta per trovare e attivare l'API di dati di YouTube. Trova eventuali altre API che la tua applicazione utilizzerà e abilita anche quelle.

Crea credenziali di autorizzazione

Qualsiasi applicazione che utilizza OAuth 2.0 per accedere alle API di Google deve avere credenziali di autorizzazione che identificano l'applicazione nel 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.

Go to the Credentials page.
Fai clic su Crea credenziali > ID client OAuth.
Seleziona il tipo di applicazione TV e dispositivi di input limitato.
Assegna un nome al client OAuth 2.0 e fai clic su Crea.

Identificare gli ambiti di accesso

Gli ambiti consentono alla tua applicazione di richiedere l'accesso solo alle risorse di cui ha bisogno, permettendo anche agli utenti di controllare la quantità di accesso che concede all'applicazione. Pertanto, potrebbe sussistere 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 dell'autorizzazione per accedere.

La versione 3 dell'API di dati di YouTube utilizza i seguenti ambiti:

Mirini con ingrandimento
https://www.googleapis.com/auth/youtube	Gestisci il tuo account YouTube
https://www.googleapis.com/auth/youtube.channel-memberships.creator	Visualizzare 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-ssl	Visualizzare, modificare ed eliminare definitivamente video, valutazioni, commenti e sottotitoli di YouTube
https://www.googleapis.com/auth/youtube.readonly	Visualizza il tuo account YouTube
https://www.googleapis.com/auth/youtube.upload	Gestisci i tuoi video su YouTube
https://www.googleapis.com/auth/youtubepartner	Visualizzare e gestire le risorse e i relativi contenuti su YouTube
https://www.googleapis.com/auth/youtubepartner-channel-audit	Visualizzare le informazioni private del tuo canale YouTube pertinenti durante la procedura di revisione con un partner di YouTube

Consulta l'elenco Ambiti consentiti per le app o i dispositivi installati.

Ottenere i token di accesso OAuth 2.0

Anche se l'applicazione viene eseguita su un dispositivo con funzionalità di input limitate, per completare questo flusso di autorizzazione gli utenti devono avere accesso separato a un dispositivo con funzionalità di input più avanzate. Il flusso prevede i seguenti passaggi:

La tua applicazione invia una richiesta al server di autorizzazione di Google che identifica gli ambiti a cui l'applicazione richiederà l'autorizzazione ad accedere.
Il server risponde con diverse informazioni utilizzate nei passaggi successivi, ad esempio un codice dispositivo e un codice utente.
Vengono mostrate le informazioni che l'utente può inserire su un dispositivo separato per autorizzare la tua app.
L'applicazione avvia il polling del server di autorizzazione di Google per determinare se l'utente ha autorizzato l'app.
L'utente passa a un dispositivo con funzionalità di input più avanzate, avvia un browser web, passa all'URL visualizzato al passaggio 3 e inserisce un codice visualizzato anche nel passaggio 3. L'utente può quindi concedere (o negare) l'accesso all'applicazione.
La risposta successiva alla richiesta di polling contiene i token necessari alla tua app per autorizzare le richieste per conto dell'utente. Se l'utente ha rifiutato l'accesso alla tua applicazione, la risposta non contiene token.

La seguente immagine illustra questo processo:

Le sezioni seguenti spiegano questi passaggi in dettaglio. Data la gamma di funzionalità e gli ambienti di runtime dei dispositivi, gli esempi mostrati in questo documento utilizzano l'utilità a riga di comando curl. Questi esempi dovrebbero essere facili da trasferire in vari linguaggi e runtime.

Passaggio 1: richiedi i codici utente e dispositivo

In questo passaggio, il dispositivo invia una richiesta POST HTTP al server di autorizzazione di Google, all'indirizzo https://oauth2.googleapis.com/device/code, che identifica la tua applicazione e gli ambiti di accesso a cui l'applicazione deve accedere per conto dell'utente. Devi recuperare questo URL dal documento di rilevamento utilizzando il valore dei metadati device_authorization_endpoint. Includi i seguenti parametri di richiesta HTTP:

Parametri

client_id

Obbligatorio

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

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. Consulta l'elenco Ambiti consentiti per le app o i dispositivi installati.

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

La versione 3 dell'API di dati di YouTube utilizza i seguenti ambiti:

Mirini con ingrandimento
https://www.googleapis.com/auth/youtube	Gestisci il tuo account YouTube
https://www.googleapis.com/auth/youtube.channel-memberships.creator	Visualizzare 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-ssl	Visualizzare, modificare ed eliminare definitivamente video, valutazioni, commenti e sottotitoli di YouTube
https://www.googleapis.com/auth/youtube.readonly	Visualizza il tuo account YouTube
https://www.googleapis.com/auth/youtube.upload	Gestisci i tuoi video su YouTube
https://www.googleapis.com/auth/youtubepartner	Visualizzare e gestire le risorse e i relativi contenuti su YouTube
https://www.googleapis.com/auth/youtubepartner-channel-audit	Visualizzare 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 puoi utilizzare per accedere alle API di Google.

Esempi

Lo snippet seguente mostra una richiesta di esempio:

POST /device/code HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly

Questo esempio mostra un comando curl per inviare la stessa richiesta:

curl -d "client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly" \
     https://oauth2.googleapis.com/device/code

Passaggio 2: gestisci la risposta del server di autorizzazione

Il server di autorizzazione restituirà una delle seguenti risposte:

Risposta riuscita

Se la richiesta è valida, la risposta sarà un oggetto JSON contenente le seguenti proprietà:

Proprietà
`device_code`	Un valore assegnato in modo univoco da Google per identificare il dispositivo che esegue l'app per cui richiede l'autorizzazione. L'utente autorizzerà il dispositivo da un altro dispositivo con funzionalità di input più complete. Ad esempio, un utente potrebbe utilizzare un laptop o un cellulare per autorizzare un'app in esecuzione su una TV. In questo caso, `device_code` identifica la TV. Questo codice consente al dispositivo che esegue l'app di determinare in modo sicuro se l'utente ha concesso o negato l'accesso.
`expires_in`	Il periodo di tempo, in secondi, di validità di `device_code` e `user_code`. Se, durante questo periodo, l'utente non completa il flusso di autorizzazione e il tuo dispositivo non esegue il polling per recuperare informazioni sulla decisione dell'utente, potrebbe essere necessario riavviare il processo dal passaggio 1.
`interval`	Il periodo di tempo, in secondi, che il dispositivo deve attendere tra una richiesta di polling e l'altra. Ad esempio, se il valore è `5`, il dispositivo deve inviare una richiesta di polling al server di autorizzazione di Google ogni cinque secondi. Per ulteriori dettagli, consulta il passaggio 3.
`user_code`	Un valore sensibile alle maiuscole che identifica a Google gli ambiti a cui l'applicazione richiede l'accesso. L'interfaccia utente indicherà all'utente di inserire questo valore su un dispositivo separato con funzionalità di input più avanzate. Google utilizza quindi il valore per visualizzare l'insieme di ambiti corretto quando viene chiesto all'utente di concedere l'accesso all'applicazione.
`verification_url`	Un URL a cui l'utente deve accedere, su un dispositivo separato, per inserire `user_code` e concedere o negare l'accesso alla tua applicazione. Anche l'interfaccia utente mostrerà questo valore.

Lo snippet seguente mostra una risposta di esempio:

{
  "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
  "user_code": "GQVQ-JKEC",
  "verification_url": "https://www.google.com/device",
  "expires_in": 1800,
  "interval": 5
}

Risposta quota superata

Se le richieste di codice del dispositivo hanno superato la quota associata al tuo ID client, riceverai una risposta 403 contenente il seguente errore:

{
  "error_code": "rate_limit_exceeded"
}

In questo caso, utilizza una strategia di backoff per ridurre la percentuale di richieste.

Passaggio 3: mostra il codice utente

Mostra all'utente i verification_url e i user_code ottenuti nel passaggio 2. Entrambi i valori possono contenere qualsiasi carattere stampabile del set di caratteri US-ASCII. I contenuti che mostri all'utente devono indicare a quest'ultimo di accedere a verification_url su un dispositivo separato e inserire il user_code.

Progetta l'interfaccia utente (UI) tenendo presenti le seguenti regole:

user_code
- user_code deve essere visualizzato in un campo in grado di gestire 15 caratteri di dimensione "W". In altre parole, se riesci a visualizzare il codice WWWWWWWWWWWWWWW correttamente, la tua UI è valida, pertanto ti consigliamo di utilizzare questo valore stringa durante il test della modalità di visualizzazione di user_code nell'interfaccia utente.
- Il campo user_code è sensibile alle maiuscole e non deve essere modificato in alcun modo, ad esempio cambiando maiuscole o minuscole o inserendo altri caratteri di formattazione.
verification_url
- Lo spazio in cui visualizzi verification_url deve essere abbastanza ampio da gestire una stringa URL di 40 caratteri.
- Non devi modificare verification_url in alcun modo, tranne nel caso in cui tu voglia rimuovere lo schema per la visualizzazione. Se prevedi di rimuovere lo schema (ad es. https://) dall'URL per motivi di visualizzazione, assicurati che la tua app sia in grado di gestire entrambe le varianti http e https.

Avviso: entrambi i valori sono soggetti a modifiche e non devi impostare come hardcoded nessuno dei due valori nel tuo codice. Allo stesso modo, non devi modificare i valori in alcun modo che non sia rimosso facoltativamente dallo schema da verification_url.

Passaggio 4: esegui un sondaggio con il server di autorizzazione di Google

Poiché l'utente utilizzerà un dispositivo separato per accedere a verification_url e concedere (o negare) l'accesso, al dispositivo richiedente non viene inviata automaticamente una notifica quando l'utente risponde alla richiesta di accesso. Per questo motivo, il dispositivo richiedente deve interrogare il server di autorizzazione di Google per determinare quando l'utente ha risposto alla richiesta.

Il dispositivo richiedente deve continuare a inviare richieste di polling fino a quando non riceve una risposta che indica che l'utente ha risposto alla richiesta di accesso o fino a quando device_code e user_code ottenuti nel passaggio 2 non sono scaduti. Il valore interval restituito nel passaggio 2 specifica la quantità di tempo, in secondi, di attesa tra una richiesta e l'altra.

L'URL dell'endpoint per il sondaggio è https://oauth2.googleapis.com/token. La richiesta di polling contiene i seguenti parametri:

Parametri
`client_id`	L'ID client della tua applicazione. Puoi trovare questo valore in API Console Credentials page.
`client_secret`	Il client secret per il `client_id` fornito. Puoi trovare questo valore in API Console Credentials page.
`device_code`	Il valore `device_code` restituito dal server di autorizzazione nel passaggio 2.
`grant_type`	Imposta questo valore su `urn:ietf:params:oauth:grant-type:device_code`.

Esempi

Lo snippet seguente mostra una richiesta di esempio:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&
client_secret=client_secret&
device_code=device_code&
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code

Questo esempio mostra un comando curl per inviare la stessa richiesta:

curl -d "client_id=client_id&client_secret=client_secret& \
         device_code=device_code& \
         grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         https://oauth2.googleapis.com/token

Passaggio 5: l'utente risponde alla richiesta di accesso

L'immagine seguente mostra una pagina simile a quella che gli utenti vedono quando visitano il verification_url che hai visualizzato nel passaggio 3:

Dopo aver inserito il user_code e, se non l'ha già fatto, aver eseguito l'accesso a Google, l'utente visualizza una schermata di consenso come quella mostrata di seguito:

Passaggio 6: gestisci le risposte alle richieste di polling

Il server di autorizzazione di Google risponde a ogni richiesta di polling con una delle seguenti risposte:

Accesso consentito

Se l'utente ha concesso l'accesso al dispositivo (facendo clic su Allow nella schermata del consenso), la risposta contiene un token di accesso e un token di aggiornamento. I token consentono al dispositivo di accedere alle API di Google per conto dell'utente. La proprietà scope nella risposta determina le API a cui il dispositivo può accedere.

In questo caso, la risposta dell'API contiene i seguenti campi:

Campi
`access_token`	Il token inviato dall'applicazione per autorizzare una richiesta API di Google.
`expires_in`	La durata rimanente del token di accesso, in secondi.
`refresh_token`	Un token che puoi utilizzare per ottenere un nuovo token di accesso. I token di aggiornamento sono validi finché l'utente non revoca l'accesso. Tieni presente che i token di aggiornamento vengono sempre restituiti per i dispositivi.
`scope`	Gli ambiti di accesso concessi da `access_token` espressi sotto forma di elenco di stringhe sensibili alle maiuscole e delimitate da spazi.
`token_type`	Il tipo di token restituito. Al momento, il valore di questo campo è sempre impostato su `Bearer`.

Lo snippet seguente mostra una risposta di esempio:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

I token di accesso hanno una durata limitata. Se la tua applicazione ha bisogno di accedere a un'API per un lungo periodo di tempo, può utilizzare il token di aggiornamento per ottenere un nuovo token di accesso. Se l'applicazione richiede questo tipo di accesso, deve archiviare il token di aggiornamento per utilizzarlo in un secondo momento.

Accesso negato

Se l'utente si rifiuta di concedere l'accesso al dispositivo, la risposta del server ha un codice di stato di risposta HTTP 403 (Forbidden). La risposta contiene il seguente errore:

{
  "error": "access_denied",
  "error_description": "Forbidden"
}

In attesa di autorizzazione

Se l'utente non ha ancora completato il flusso di autorizzazione, il server restituisce un codice di stato di risposta HTTP 428 (Precondition Required). La risposta contiene il seguente errore:

{
  "error": "authorization_pending",
  "error_description": "Precondition Required"
}

Sondaggi troppo frequenti

Se il dispositivo invia richieste di polling troppo spesso, il server restituisce un codice di stato di risposta HTTP 403 (Forbidden). La risposta contiene il seguente errore:

{
  "error": "slow_down",
  "error_description": "Forbidden"
}

Altri errori

Il server di autorizzazione restituisce errori anche se nella richiesta di polling mancano parametri obbligatori o se il valore parametro è errato. Queste richieste di solito hanno un codice di stato di risposta HTTP 400 (Bad Request) o 401 (Unauthorized). Questi errori includono:

Errore	Codice di stato HTTP	Descrizione
`admin_policy_enforced`	`400`	L'Account Google non è in grado di autorizzare uno o più ambiti richiesti a causa delle norme dell'amministratore di Google Workspace. Per saperne di più su come un amministratore può limitare l'accesso agli ambiti finché l'accesso non viene concesso esplicitamente al tuo ID client OAuth, consulta l'articolo del Centro assistenza per amministratori di Google Workspace Specificare quali app di terze parti e interne possono accedere ai dati di Google Workspace.
`invalid_client`	`401`	Client OAuth non trovato. Ad esempio, questo errore si verifica se il valore del parametro `client_id` non è valido. Il tipo di client OAuth non è corretto. Assicurati che il tipo di applicazione per l'ID client sia impostato su TV e dispositivi di input con limitazioni.
`invalid_grant`	`400`	Il valore del parametro `code` non è valido, è già stato rivendicato o non può essere analizzato.
`unsupported_grant_type`	`400`	Il valore del parametro `grant_type` non è valido.
`org_internal`	`403`	L'ID client OAuth nella richiesta fa parte di un progetto che limita l'accesso agli Account Google in una specifica organizzazione Google Cloud. Conferma la configurazione del tipo di utente per l'applicazione OAuth.

Chiamata alle API di Google

Dopo che l'applicazione ha ottenuto un token di accesso, puoi utilizzare il token 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 questo scopo, 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 utilizzare l'intestazione HTTP, in quanto 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, durante la chiamata all'API di dati di YouTube).

Tieni presente che l'API di dati di YouTube supporta gli account di servizio solo per i proprietari di contenuti di YouTube che possiedono e gestiscono più canali YouTube, come case discografiche e studi cinematografici.

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

Esempi di HTTP GET

Una chiamata all'endpoint youtube.channels (l'API di dati di YouTube) 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/channels?part=snippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Di seguito è riportata una chiamata alla stessa API per l'utente autenticato utilizzando il parametro della stringa di query access_token:

GET https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

Esempi di `curl`

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/youtube/v3/channels?part=snippet&mine=true

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

curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

Aggiornare un token di accesso

I token di accesso scadono periodicamente e diventano credenziali non valide per una richiesta API correlata. Puoi aggiornare un token di accesso senza chiedere all'utente l'autorizzazione (anche quando l'utente non è presente) se hai richiesto l'accesso offline agli ambiti associati al token.

Per aggiornare un token di accesso, l'applicazione invia una richiesta POST HTTPS al server di autorizzazione di Google (https://oauth2.googleapis.com/token) che include i seguenti parametri:

Campi
`client_id`	L'ID client ottenuto da API Console.
`client_secret`	Il client secret ottenuto da API Console.
`grant_type`	Come definito nella specifica OAuth 2.0, il valore di questo campo deve essere impostato su `refresh_token`.
`refresh_token`	Il token di aggiornamento restituito dallo scambio di codici di autorizzazione.

Lo snippet seguente mostra una richiesta di esempio:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

Se l'utente non ha revocato l'accesso concesso all'applicazione, il server token restituisce un oggetto JSON contenente un nuovo token di accesso. Lo snippet seguente mostra una risposta di esempio:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

Tieni presente che sono previsti limiti al numero di token di aggiornamento che verranno emessi: un limite per combinazione client/utente e un altro per utente in tutti i client. Dovresti salvare i token di aggiornamento nello spazio di archiviazione a lungo termine e continuare a utilizzarli finché rimangono validi. Se l'applicazione richiede troppi token di aggiornamento, potrebbe raggiungere questi limiti, nel qual caso i token di aggiornamento precedenti smetteranno di funzionare.

Revoca di un token

In alcuni casi un utente può voler revocare l'accesso concesso a un'applicazione. Un utente può revocare l'accesso visitando le Impostazioni account. Per maggiori informazioni, consulta la sezione dedicata alla rimozione dell'accesso a siti o app del documento di assistenza su siti e app di terze parti con accesso al tuo account.

È anche possibile che un'applicazione revochi in modo programmatico l'accesso concesso. La revoca 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 concesse in precedenza all'applicazione vengano rimosse.

Per revocare un token in modo programmatico, l'applicazione effettua 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.

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.

Ambiti consentiti

Il flusso OAuth 2.0 per i dispositivi è supportato solo per i seguenti ambiti:

email
openid
profile

API Drive

https://www.googleapis.com/auth/drive.appdata
https://www.googleapis.com/auth/drive.file

API di YouTube

https://www.googleapis.com/auth/youtube
https://www.googleapis.com/auth/youtube.readonly