Questo documento spiega come implementare l'autorizzazione OAuth 2.0 per accedere all'API YouTube Data tramite applicazioni in esecuzione su dispositivi come TV, console per videogiochi e stampanti. Più nello specifico, questo flusso è progettato per i dispositivi che non hanno accesso a un browser o che hanno funzionalità di input limitate.
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 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 a singoli dispositivi, si presume che non possano mantenere segreti. 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 Windows universale), che ha accesso al browser e funzionalità di input complete, utilizza il flusso OAuth 2.0 per applicazioni mobile e desktop. (Devi utilizzare questo flusso anche se la tua app è uno strumento a riga di comando senza un'interfaccia grafica.)
Se vuoi solo consentire agli utenti di accedere con i propri Account Google e utilizzare il token ID JWT per ottenere le informazioni di base del profilo utente, consulta la sezione Accedi su TV e dispositivi di input limitati.
Prerequisiti
Abilitare le API per il progetto
Qualsiasi applicazione che chiama le API di Google deve abilitarle in API Console.
Per abilitare un'API per il tuo progetto:
- Open the API Library nella Google API Console.
- If prompted, select a project, or create a new one.
- Utilizza la pagina Libreria per trovare e abilitare l'API di dati di YouTube. Trova altre API che la tua applicazione utilizzerà e abilita anche queste.
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 creare le credenziali per il tuo progetto. Le tue applicazioni possono quindi utilizzare le credenziali per accedere alle API che hai abilitato per quel progetto.
- Go to the Credentials page.
- Fai clic su Crea cliente.
- Seleziona il tipo di applicazione TV e dispositivi a 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, consentendo al contempo agli utenti di controllare la quantità di accesso che concedono 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 dovrà accedere.
L'API YouTube Data v3 utilizza i seguenti ambiti:
| Ambito | Descrizione |
|---|---|
https://www. |
Gestisci il tuo account YouTube |
https://www. |
Visualizzare un elenco dei tuoi attuali membri attivi del canale, il loro livello corrente e quando sono diventati membri |
https://www. |
Visualizzare, modificare ed eliminare definitivamente video, valutazioni, commenti e sottotitoli di YouTube. |
https://www. |
Visualizza il tuo account YouTube |
https://www. |
Gestisci i tuoi video su YouTube |
https://www. |
Visualizzare e gestire le risorse e i relativi contenuti su YouTube |
https://www. |
Visualizzare le informazioni private del tuo canale YouTube pertinenti durante la procedura di revisione con un partner di YouTube |
Consulta l'elenco degli ambiti consentiti per le app o i dispositivi installati.
Ottenere token di accesso OAuth 2.0
Anche se la tua applicazione viene eseguita su un dispositivo con funzionalità di input limitate, gli utenti devono avere accesso separato a un dispositivo con funzionalità di input più avanzate per completare questo flusso di autorizzazione. Il flusso prevede i seguenti passaggi:
- La tua applicazione invia una richiesta al server di autorizzazione di Google che identifica gli ambiti per cui la tua applicazione richiederà l'autorizzazione di accesso.
- Il server risponde con diverse informazioni utilizzate nei passaggi successivi, ad esempio un codice dispositivo e un codice utente.
- Visualizzi le informazioni che l'utente può inserire su un dispositivo separato per autorizzare la tua app.
- La tua applicazione inizia a eseguire il polling del server di autorizzazione di Google per determinare se l'utente ha autorizzato la tua app.
- L'utente passa a un dispositivo con funzionalità di input più avanzate, avvia un browser web, va all'URL visualizzato nel passaggio 3 e inserisce un codice visualizzato anch'esso nel passaggio 3. L'utente può quindi concedere (o negare) l'accesso alla tua applicazione.
- La risposta successiva alla tua 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.)
L'immagine seguente illustra questo processo:
Le sezioni seguenti spiegano in dettaglio questi passaggi. Data la gamma di funzionalità e ambienti di runtime
che i dispositivi possono avere, gli esempi mostrati in questo documento utilizzano l'utilità della riga di comando curl. Questi esempi dovrebbero essere facili da trasferire a varie lingue e runtime.
Passaggio 1: richiedi i codici del dispositivo e dell'utente
In questo passaggio, il dispositivo invia una richiesta HTTP POST 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 la tua applicazione vuole 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
della richiesta HTTP:
| Parametri | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
Obbligatorio
L'ID client della tua applicazione. Puoi trovare questo valore in . |
||||||||||||||||
scope |
Obbligatorio
Un elenco delimitato da spazi di ambiti che identificano le risorse a cui la tua applicazione potrebbe accedere per conto dell'utente. Questi valori informano la schermata di consenso che Google mostra all'utente. Consulta l'elenco degli 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, 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:
Il documento Ambiti API OAuth 2.0 fornisce un elenco completo degli ambiti che puoi utilizzare per accedere alle API di Google. |
||||||||||||||||
Esempi
Il seguente snippet 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 di successo
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 che richiede
l'autorizzazione. L'utente autorizzerà il dispositivo da un altro dispositivo con funzionalità di input più avanzate. 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, durante il quale device_code e
user_code sono validi. Se, in questo periodo di tempo, l'utente non completa il
flusso di autorizzazione e il tuo dispositivo non esegue il polling per recuperare informazioni sulla
decisione dell'utente, potresti dover riavviare la procedura dal passaggio 1. |
interval |
Il periodo di tempo, in secondi, che il dispositivo deve attendere tra le richieste di polling. Ad esempio, se il valore è 5, il dispositivo deve inviare una richiesta di polling al server di autorizzazione di Google ogni cinque secondi. Per maggiori dettagli, vedi il passaggio 3. |
user_code |
Un valore sensibile alle maiuscole e minuscole che identifica per Google gli ambiti a cui l'applicazione richiede l'accesso. L'interfaccia utente chiederà all'utente di inserire questo valore su un dispositivo separato con funzionalità di input più avanzate. Google utilizza poi il valore per mostrare il set corretto di ambiti quando chiede all'utente di concedere l'accesso alla tua applicazione. |
verification_url |
Un URL a cui l'utente deve accedere su un dispositivo separato per inserire il
user_code e concedere o negare l'accesso alla tua applicazione. Anche l'interfaccia utente
mostrerà questo valore. |
Il seguente snippet 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 di superamento della quota
Se le richieste di codice 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 frequenza delle richieste.
Passaggio 3: visualizza il codice utente
Mostra all'utente verification_url e 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 invitarlo ad andare su
verification_url su un dispositivo separato e inserire user_code.
Progetta l'interfaccia utente tenendo presente le seguenti regole:
user_code- Il
user_codedeve essere visualizzato in un campo che può gestire 15 caratteri di dimensione "W". In altre parole, se riesci a visualizzare correttamente il codiceWWWWWWWWWWWWWWW, la tua UI è valida e ti consigliamo di utilizzare questo valore stringa quando testi il modo in cuiuser_codeviene visualizzato nella tua UI. - Il
user_codeè sensibile alle maiuscole e non deve essere modificato in alcun modo, ad esempio cambiando le maiuscole o inserendo altri caratteri di formattazione.
- Il
verification_url- Lo spazio in cui visualizzi
verification_urldeve essere abbastanza ampio da gestire una stringa URL di 40 caratteri. - Non devi modificare
verification_urlin alcun modo, tranne per rimuovere facoltativamente 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 possa gestire le variantihttpehttps.
- Lo spazio in cui visualizzi
Passaggio 4: esegui il polling del server di autorizzazione di Google
Poiché l'utente utilizzerà un dispositivo separato per accedere a verification_url
e concedere (o negare) l'accesso, il dispositivo richiedente non riceve automaticamente una notifica quando l'utente
risponde alla richiesta di accesso. Per questo motivo, il dispositivo richiedente deve eseguire il polling del server di autorizzazione di Google per determinare quando l'utente ha risposto alla richiesta.
Il dispositivo richiedente deve continuare a inviare richieste di polling finché non riceve una risposta
che indica che l'utente ha risposto alla richiesta di accesso o finché device_code
e user_code ottenuti nel
passaggio 2 non sono scaduti. Il valore interval restituito nel passaggio 2 specifica il tempo di attesa, in secondi, tra le richieste.
L'URL dell'endpoint da interrogare è 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 . |
client_secret |
Il client secret per il client_id fornito. Puoi trovare questo valore in
. |
device_code |
Il device_code restituito dal server di autorizzazione nel
passaggio 2. |
grant_type |
Imposta urn:ietf:params:oauth:grant-type:device_code per questo valore. |
Esempi
Il seguente snippet 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/tokenPassaggio 5: l'utente risponde alla richiesta di accesso
La seguente immagine mostra una pagina simile a quella visualizzata dagli utenti quando accedono al
verification_url che hai mostrato nel passaggio 3:
Dopo aver inserito il user_code e, se non ha già eseguito l'accesso, 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 sondaggio
Il server di autorizzazione di Google risponde a ogni richiesta di polling con una delle seguenti risposte:
Accesso concesso
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 a quali API può accedere il
dispositivo.)
In questo caso, la risposta dell'API contiene i seguenti campi:
| Campi | |
|---|---|
access_token |
Il token che la tua applicazione invia 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 o il token di aggiornamento non scade. Tieni presente che i token di aggiornamento vengono sempre restituiti per i dispositivi. |
refresh_token_expires_in |
La durata rimanente del token di aggiornamento in secondi. Questo valore viene impostato solo quando l'utente concede l'accesso basato sul tempo. |
scope |
Gli ambiti di accesso concessi da access_token espressi come elenco di
stringhe sensibili alle maiuscole e minuscole delimitate da spazi. |
token_type |
Il tipo di token restituito. Al momento, il valore di questo campo è sempre impostato su
Bearer. |
Il seguente snippet 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 deve accedere a un'API per un lungo periodo di tempo, può utilizzare il token di aggiornamento per ottenere un nuovo token di accesso. Se la tua applicazione ha bisogno di questo tipo di accesso, deve memorizzare il token di aggiornamento per un utilizzo successivo.
Accesso negato
Se l'utente rifiuta di concedere l'accesso al dispositivo, la risposta del server ha un
codice di stato HTTP 403 (Forbidden). La risposta contiene il seguente errore:
{ "error": "access_denied", "error_description": "Forbidden" }
Autorizzazione in attesa
Se l'utente non ha ancora completato il flusso di autorizzazione, il server restituisce un codice di stato della risposta HTTP 428 (Precondition Required). La risposta contiene il seguente errore:
{ "error": "authorization_pending", "error_description": "Precondition Required" }
Polling troppo frequente
Se il dispositivo invia richieste di polling troppo spesso, il server restituisce un codice di stato della 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 un parametro ha un valore errato. Queste richieste in genere hanno un codice di stato della 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 del suo amministratore di Google Workspace. Per saperne di più su come un amministratore può limitare l'accesso agli ambiti finché non viene concesso esplicitamente l'accesso al tuo ID client OAuth, consulta l'articolo del Centro assistenza Amministratore Google Workspace Specificare quali app di terze parti e interne possono accedere ai dati di Google Workspace. |
invalid_client |
401 |
Il client OAuth non è stato trovato. Ad esempio, questo errore si verifica se il valore del parametro
Il tipo di client OAuth non è corretto. Assicurati che il tipo di applicazione per l'ID client sia impostato su TV e dispositivi a input limitato. |
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 un' organizzazione Google Cloud specifica. Conferma la configurazione del tipo di utente per la tua applicazione OAuth. |
Chiamata alle API di Google
Una volta che l'applicazione ottiene un token di accesso, puoi utilizzarlo per effettuare chiamate a un'API Google per conto di un determinato 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 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 Data).
Tieni presente che l'API YouTube Data 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 visualizzare i relativi ambiti in OAuth 2.0 Playground.
Esempi di HTTP GET
Una chiamata all'endpoint
youtube.channels (l'API YouTube Data) utilizzando 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
Ecco 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
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/youtube/v3/channels?part=snippet&mine=true
In alternativa, l'opzione del parametro stringa di query:
curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true
Aggiornamento di 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 l'autorizzazione all'utente (anche quando l'utente non è presente) se hai richiesto l'accesso offline agli ambiti associati al token.
Per aggiornare un token di accesso, la tua applicazione invia una richiesta HTTPS POST
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 del codice di autorizzazione. |
Il seguente snippet 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
Finché l'utente non ha revocato l'accesso concesso all'applicazione, il server dei token restituisce un oggetto JSON contenente un nuovo token di accesso. Il seguente snippet 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 esiste un limite al numero di token di aggiornamento che verranno emessi: un limite per combinazione client/utente e un altro per utente in tutti i client. Devi salvare i token di aggiornamento in uno spazio di archiviazione a lungo termine e continuare a utilizzarli finché rimangono validi. Se la tua applicazione richiede troppi token di aggiornamento, potrebbe raggiungere questi limiti, nel qual caso i token di aggiornamento meno recenti smetteranno di funzionare.
Revoca del token
In alcuni casi, un utente potrebbe voler revocare l'accesso concesso a un'applicazione. Un utente può revocare l'accesso visitando le impostazioni dell'account. Per saperne di più, consulta la sezione Rimuovere l'accesso di un sito o di un'app del documento di assistenza App e siti di terze parti con accesso al tuo account.
È anche possibile che un'applicazione revochi a livello di programmazione 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 API richieste da un'app sono cambiate in modo significativo. In altre parole, parte della procedura di rimozione può includere una richiesta API per garantire che le autorizzazioni precedentemente concesse all'applicazione vengano rimosse.
Per revocare un token a livello di programmazione, la tua applicazione invia una richiesta a
https://oauth2.googleapis.com/revoke e include il token come parametro:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
https://oauth2.googleapis.com/revoke?token={token}Il token può essere un token di accesso o un token di aggiornamento. Se il token è un token di accesso e ha un token di aggiornamento corrispondente, verrà revocato anche il token di aggiornamento.
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:
OpenID Connect, Accedi con Google
emailopenidprofile
API Drive
https://www.googleapis.com/auth/drive.appdatahttps://www.googleapis.com/auth/drive.file
API di YouTube
https://www.googleapis.com/auth/youtubehttps://www.googleapis.com/auth/youtube.readonly
Accesso in base al tempo
L'accesso basato sul tempo consente a un utente di concedere alla tua app l'accesso ai propri dati per un periodo di tempo limitato per completare un'azione. L'accesso temporaneo è disponibile in alcuni prodotti Google durante il flusso di consenso, offrendo agli utenti la possibilità di concedere l'accesso per un periodo di tempo limitato. Un esempio è l' API Data Portability, che consente un trasferimento una tantum dei dati.
Quando un utente concede alla tua applicazione l'accesso basato sul tempo, il token di aggiornamento scade dopo la durata specificata. Tieni presente che i token di aggiornamento potrebbero essere invalidati prima in circostanze specifiche. Per ulteriori dettagli, consulta questi casi. Il campo refresh_token_expires_in restituito nella risposta di scambio del codice di autorizzazione rappresenta il tempo rimanente prima della scadenza del token di aggiornamento in questi casi.
Implementare la Protezione su più account
Un ulteriore passaggio da intraprendere per proteggere gli account dei tuoi utenti è l'implementazione della protezione cross-account utilizzando il servizio di protezione cross-account di Google. Questo servizio ti consente di abbonarti alle notifiche degli eventi di sicurezza, che forniscono alla tua applicazione informazioni sulle modifiche principali all'account utente. Puoi quindi utilizzare le informazioni per intervenire a seconda di come decidi di rispondere agli eventi.
Ecco alcuni esempi dei tipi di eventi inviati alla tua app dal servizio di protezione cross-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 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 .