OAuth 2.0 per app mobile e desktop

Questo documento spiega in che modo le applicazioni desktop (come le applicazioni in esecuzione su Windows, macOS o Linux o gli strumenti dell'interfaccia a riga di comando (CLI)) utilizzano gli endpoint OAuth 2.0 di Google per autorizzare l'accesso all'API YouTube Data.

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 caricare video sul canale YouTube di un utente.

Le applicazioni desktop vengono installate localmente sulla macchina di un utente (ad esempio software desktop autonomo, strumenti CLI per sviluppatori, utilità di sincronizzazione in background o script). Poiché queste app vengono distribuite ai singoli dispositivi, si presume che non possano mantenere segreti (sono client pubblici). Possono accedere alle API di Google mentre l'utente interagisce attivamente con l'app o quando l'app è in esecuzione in background.

Questo flusso di autorizzazione è simile a quello utilizzato per le applicazioni server web. La differenza principale è che le app desktop devono aprire il browser di sistema e fornire un URI di reindirizzamento locale (ad esempio un indirizzo IP di loopback) per gestire le risposte dal server di autorizzazione di Google.

Librerie ed esempi

Ti consigliamo di utilizzare le librerie client delle API di Google per il tuo linguaggio di programmazione (ad es. Python, Java, Node.js, Go, .NET) quando implementi OAuth 2.0 per le applicazioni desktop. Le librerie client gestiscono l'autorizzazione degli utenti e la gestione dei token, semplificando l'implementazione e riducendo il rischio di errori rispetto all'utilizzo diretto degli endpoint HTTP/REST di livello inferiore.

Per le app mobile, consulta le guide all'autorizzazione per Android e iOS.

Per le app in esecuzione su dispositivi che non supportano un browser di sistema o che hanno funzionalità di immissione limitate, come TV, console per videogiochi, fotocamere o stampanti, consulta OAuth 2.0 per TV e dispositivi o Accedi su TV e dispositivi di immissione limitata.

Prerequisiti

Abilita le API per il tuo progetto

Qualsiasi applicazione che chiama le API di Google deve abilitarle nella console API.

Per abilitare un'API per il tuo progetto:

1. Apri la libreria API nella console API di Google.
2. Se richiesto, seleziona un progetto o creane uno nuovo.
3. Utilizza la pagina Libreria per trovare e attivare l'API YouTube Data. Trova altre API che verranno utilizzate dalla tua applicazione 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 la identificano per il 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.

1. Vai alla pagina Clienti.
2. Fai clic su Crea client.
3. Seleziona il tipo di applicazione App desktop.
4. Nel campo Nome, inserisci un nome per il client OAuth. Questo nome viene visualizzato nella pagina Clienti del progetto per identificare il client.
5. Fai clic su Crea.

L'ID client e il client secret vengono generati e visualizzati nella console Google Cloud. Le app desktop sono client pubblici e non possono mantenere riservati i secret. Utilizza sempre PKCE (Proof Key for Code Exchange) quando richiedi i codici di autorizzazione.

Identifica 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 il livello 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 per cui la tua app avrà bisogno dell'autorizzazione di accesso.

L'API YouTube Data v3 utilizza i seguenti ambiti:

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 seguenti mostrano come l'applicazione interagisce con il server OAuth 2.0 di Google per ottenere il consenso di un utente a eseguire una richiesta API per suo conto. La tua applicazione deve avere questo consenso prima di poter eseguire una richiesta API di Google che richiede l'autorizzazione dell'utente.

Passaggio 1: genera un verificatore di codice e una verifica

Google supporta il protocollo Proof Key for Code Exchange (PKCE) per rendere più sicuro il flusso delle app installate. Per ogni richiesta di autorizzazione viene creato un verificatore di codice univoco e il suo valore trasformato, chiamato "code_challenge", viene inviato al server di autorizzazione per ottenere il codice di autorizzazione.

Crea il verificatore del codice

Un code_verifier è una stringa casuale crittografica ad alta entropia che utilizza i caratteri non riservati [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~", con una lunghezza minima di 43 caratteri e una lunghezza massima di 128 caratteri.

Il verificatore del codice deve avere un'entropia sufficiente per rendere impossibile indovinare il valore.

Crea la verifica con codice

Sono supportati due metodi per creare la verifica del codice.

code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

code_challenge = code_verifier

Passaggio 2: invia una richiesta al server OAuth 2.0 di Google

Per ottenere l'autorizzazione dell'utente, invia una richiesta al server di autorizzazione di Google all'indirizzo https://accounts.google.com/o/oauth2/v2/auth. Questo endpoint gestisce la ricerca delle sessioni di attività attive, autentica l'utente e ottiene il consenso dell'utente. L'endpoint è accessibile solo tramite SSL e rifiuta le connessioni HTTP (non SSL).

Il server di autorizzazione supporta i seguenti parametri della stringa di query per le applicazioni installate:

URL di autorizzazione di esempio

Le schede di seguito mostrano URL di autorizzazione di esempio per le diverse opzioni di URI di reindirizzamento.

Gli URL sono identici, ad eccezione del valore del parametro redirect_uri. Gli URL contengono anche i parametri obbligatori response_type e client_id, nonché il parametro facoltativo state. Ogni URL contiene interruzioni di riga e spazi per la leggibilità.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

Passaggio 3: Google chiede il consenso dell'utente

In questo passaggio, l'utente decide se concedere alla tua applicazione l'accesso richiesto. In questa fase, Google mostra una finestra di consenso che riporta il nome della tua applicazione e i servizi API di Google per cui richiede l'autorizzazione di accesso con le credenziali di autorizzazione dell'utente, nonché 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, ma deve attendere la risposta del server OAuth 2.0 di Google che indica se è stato concesso l'accesso. La risposta è spiegata nel passaggio successivo.

Passaggio 4: gestisci la risposta del server OAuth 2.0

Il modo in cui l'applicazione riceve la risposta di autorizzazione dipende dallo schema URI di reindirizzamento che utilizza. Indipendentemente dallo schema, la risposta conterrà un codice di autorizzazione (code) o un errore (error). Ad esempio, error=access_denied indica che l'utente ha rifiutato la richiesta.

Se l'utente concede l'accesso alla tua applicazione, puoi scambiare il codice di autorizzazione con un token di accesso e un token di aggiornamento, come descritto nel passaggio successivo.

Passaggio 5: scambia il codice di autorizzazione con i token di aggiornamento e di accesso

Per scambiare un codice di autorizzazione con un token di accesso, chiama l'endpoint https://oauth2.googleapis.com/token e imposta i seguenti parametri:

Sebbene l'utilizzo di DPoP sia facoltativo, è consigliato per una maggiore sicurezza. La sicurezza di DPoP si basa sulla limitazione della chiave privata a un singolo dispositivo; ti consigliamo di archiviarla in modo che non possa essere copiata fuori dal dispositivo, ad esempio utilizzando TPM, Secure Enclave o altri keystore con crittografia hardware. Per utilizzare DPoP, l'applicazione deve generare un nuovo JWT di prova DPoP univoco per ogni richiesta all'endpoint del token e aggiungerlo come intestazione della richiesta HTTP.

Il seguente snippet mostra una richiesta di esempio:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

Crea una prova DPoP

I passaggi seguenti mostrano come creare una prova DPoP utilizzando OpenSSL dalla riga di comando:

1. Genera una coppia di chiavi EC P-256:

   openssl ecparam -name prime256v1 -genkey -noout -out dpop_private.pem
   openssl ec -in dpop_private.pem -pubout -out dpop_public.pem

2. Crea l'intestazione DPoP:

   L'intestazione deve includere le attestazioni typ, alg e jwk (chiave pubblica). I valori x e y sono le coordinate con codifica Base64Url della tua chiave pubblica EC. Codifica questo JSON in Base64Url:

   {
     "typ":"dpop+jwt",
     "alg":"ES256",
     "jwk": {
       "kty":"EC",
       "x":"YOUR_PUBLIC_KEY_X",
       "y":"YOUR_PUBLIC_KEY_Y",
       "crv":"P-256"
     }
   }

3. Crea il payload DPoP:

   Il payload deve includere jti (un identificatore univoco per la richiesta), htm (metodo HTTP, ad esempio POST), htu (URI HTTP, ad esempio https://oauth2.googleapis.com/token) e iat (ora di emissione). Se hai ricevuto un nonce dal server in un'intestazione DPoP-Nonce nella risposta a una richiesta precedente, devi includere il valore del nonce in un claim nonce. La dichiarazione nonce è facoltativa per gli scambi di codici di autorizzazione e viene utilizzata solo quando l'intestazione DPoP-Nonce è stata ricevuta in precedenza. Codifica questo JSON in Base64Url:

   {
     "jti":"JTI_VALUE",
     "htm":"POST",
     "htu":"https://oauth2.googleapis.com/token",
     "iat":YOUR_JWT_ISSUED_TIME,
     "nonce":"SERVER_PROVIDED_NONCE"
   }

   Il valore jti dipende dal tipo di piattaforma di scambio:

   • Per gli scambi di codici di autorizzazione, jti deve essere l'hash SHA256 con codifica Base64Url del codice di autorizzazione: "jti":"BASE64URL(SHA256(AUTHORIZATION_CODE))".
   • Per gli scambi di token di aggiornamento, jti deve essere un identificatore univoco per richiesta: "jti":"YOUR_UNIQUE_PER_REQUEST_IDENTIFIER".
4. Firma la bozza:

   Concatena l'intestazione e il payload codificati con un punto (.), quindi firma il risultato con la tua chiave privata utilizzando ES256. Tieni presente che JWS richiede che la firma sia in un formato concatenato R | S non elaborato (64 byte per P-256). Se utilizzi direttamente OpenSSL, devi convertire la firma predefinita con codifica ASN.1 DER in questo formato non elaborato.

Uno scambio riuscito è indicato da una risposta 200 OK contenente i token. Se durante lo scambio viene utilizzata una prova DPoP valida, il token di aggiornamento restituito da Google sarà associato alla tua chiave tramite DPoP, ma i token di accesso non saranno associati tramite DPoP. I token di accesso manterranno il token_type di Bearer anziché DPoP. Inoltre, Google restituisce un'intestazione HTTP DPoP-Nonce nella risposta. Il client deve memorizzare nella cache questo nonce e includerlo nella dichiarazione nonce della prova DPoP nelle richieste successive (ad esempio quando scambia un token di aggiornamento con un nuovo token di accesso o quando chiama API protette da DPoP). Utilizzando questo nonce emesso in anticipo, puoi evitare un errore di round trip aggiuntivo (use_dpop_nonce) nella richiesta successiva.

Le prove DPoP devono essere incluse per le richieste di scambio di token effettuate con token di aggiornamento associati a DPoP.

Uno scambio non riuscito si verifica se l'intestazione DPoP non è presente quando prevista, non è valida o se la prova utilizza una chiave diversa da quella associata al token. In questi casi, il server restituisce un errore 400 Bad Request. Se la prova DPoP presenta attestazioni htm o htu non corrispondenti, un'attestazione iat scaduta, un'attestazione jti riutilizzata o una firma non valida, Google restituisce un codice di errore invalid_dpop_proof. Se è richiesto un nonce DPoP, ad esempio durante uno scambio di token di aggiornamento, e nella prova DPoP manca un claim nonce o il valore del nonce non è accettabile per il server (ad esempio, è scaduto, è già stato utilizzato o non è corretto), Google restituisce un codice di errore use_dpop_nonce insieme a un'intestazione HTTP DPoP-Nonce contenente un nuovo nonce che puoi utilizzare in una richiesta successiva. Altri errori potrebbero restituire invalid_grant.

Google risponde a questa richiesta restituendo un oggetto JSON che contiene un token di accesso di breve durata e un token di aggiornamento.

La risposta contiene i seguenti campi:

Il seguente snippet mostra un esempio di intestazioni e corpo della risposta corretta quando viene utilizzato DPoP:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

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

Passaggio 6: controlla gli ambiti concessi dagli utenti

Quando richiedi più autorizzazioni (ambiti), gli utenti potrebbero non concedere alla tua app l'accesso a tutte. La tua app deve verificare quali ambiti sono stati effettivamente concessi e gestire correttamente le situazioni in cui alcune autorizzazioni vengono negate, in genere disattivando le funzionalità che si basano su questi ambiti negati.

Tuttavia, ci sono delle eccezioni. Le app Google Workspace Enterprise con delega di autorità a livello di dominio o le app contrassegnate come Attendibili ignorano la schermata per il consenso alle autorizzazioni granulari. Per queste app, gli utenti non vedranno la schermata per il consenso alle autorizzazioni granulari. La tua app riceverà invece tutti gli ambiti richiesti o nessuno.

Per informazioni più dettagliate, consulta Come gestire le autorizzazioni granulari.

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 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'autorizzazione per visualizzare, modificare ed eliminare definitivamente i video di YouTube, le valutazioni, i commenti e i sottotitoli dell'utente:

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

Chiama le API di Google

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 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 dei 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) 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

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/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

Aggiorna 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, l'applicazione invia una richiesta HTTPS POST al server di autorizzazione di Google (https://oauth2.googleapis.com/token) che include i seguenti parametri nel corpo della richiesta:

Sebbene l'utilizzo di DPoP sia facoltativo, è consigliato per una maggiore sicurezza. Per utilizzare DPoP con un token di aggiornamento, l'applicazione deve generare un nuovo JWT di prova DPoP univoco per ogni richiesta all'endpoint del token. Questa prova deve essere firmata con la stessa chiave privata utilizzata durante lo scambio iniziale del codice di autorizzazione. La tua applicazione aggiunge la prova come intestazione della richiesta HTTP.

Il seguente snippet mostra una richiesta di esempio:

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

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

Per utilizzare DPoP con un token di aggiornamento, devi generare un nuovo JWT di prova DPoP univoco per la richiesta. Consulta Crea una prova DPoP per istruzioni passo passo sulla generazione della coppia di chiavi e sulla creazione del JWT.

Uno scambio riuscito è indicato da una risposta 200 OK contenente un nuovo token di accesso. Quando viene utilizzato DPoP, token_type è Bearer. Una risposta positiva conferma che la prova DPoP per il token di aggiornamento è stata accettata. Google potrebbe anche restituire una nuova intestazione HTTP DPoP-Nonce nella risposta. Se restituita, il client deve memorizzare nella cache questo nonce e includerlo nella rivendicazione nonce della prova DPoP nelle richieste successive.

Uno scambio non riuscito si verifica se l'intestazione DPoP è mancante, non valida o utilizza una chiave errata. Per informazioni dettagliate su codici di errore DPoP specifici e sulla gestione dei nonce, consulta Scambio non riuscito.

Il seguente snippet mostra un esempio di intestazioni e corpo della risposta corretta quando viene utilizzato DPoP:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

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

Tieni presente che esistono 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. Devi salvare i token di aggiornamento nello 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 e, in questo caso, i token di aggiornamento meno recenti smetteranno di funzionare.

Revoca dei 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 ulteriori informazioni, consulta la sezione Rimuovere l'accesso di un sito o di un'app del documento di assistenza Siti e app di terze parti con accesso al tuo account.

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

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

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

Metodi di reindirizzamento alle app

Proteggi le tue app

Accesso in base al tempo

L'accesso basato sul tempo consente a un utente di concedere alla tua app l'accesso ai suoi dati per un periodo di tempo limitato per completare un'azione. L'accesso basato sul tempo è disponibile in alcuni prodotti Google durante il flusso di consenso e offre agli utenti la possibilità di concedere l'accesso per un periodo di tempo limitato. Un esempio è l' API Data Portability, che consente un trasferimento dei dati una tantum.

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 maggiori dettagli, consulta questi casi. In questi casi, il campo refresh_token_expires_in restituito nella risposta dello scambio del codice di autorizzazione rappresenta il tempo rimanente prima della scadenza del token di aggiornamento.

Per approfondire

La best practice attuale dell'IETF OAuth 2.0 for App native stabilisce molte delle best practice documentate qui.