Ho utilizzato il token di aggiornamento più volte in un breve periodo a scopo di test, ma mi chiedo se i token di aggiornamento di Google scadono mai? Posso utilizzare lo stesso token di aggiornamento per ottenere un altro token di accesso ancora e ancora per un lungo periodo (una settimana o addirittura mesi)?
Risposte:
I token di aggiornamento emessi dal server Google Auth non scadono mai: questo è il punto centrale dei token di aggiornamento. Il token di aggiornamento scadrà (o dovrei dire non sarà autorizzato) quando l'utente revocherà l'accesso alla tua applicazione.
Fare riferimento a questo documento che indica chiaramente la funzione dei token di aggiornamento.
Invece di emettere un token di lunga durata (in genere valido per un anno o durata illimitata), il server può emettere un token di accesso di breve durata e un token di aggiornamento di lunga durata. Quindi, in breve, puoi utilizzare i token di aggiornamento ancora e ancora fino a quando l'utente che ha autorizzato l'accesso revoca l'accesso alla tua applicazione.
Questo è un thread molto confuso. La prima risposta sembra essere corretta, ma in realtà non cita nulla di autorevole da parte di Google.
La risposta più definitiva che ho trovato è in realtà nel parco giochi dello sviluppatore dove ottieni il token. Il passaggio 2 ha una nota in basso che dice:
"Nota: OAuth Playground non memorizza i token di aggiornamento, ma poiché i token di aggiornamento non scadono mai, l'utente deve andare alla pagina di accesso autorizzato dell'account Google se desidera revocarli manualmente."
Non penso che sia completamente vero:
Nota che ci sono limiti al numero di token di aggiornamento che verranno emessi; un limite per combinazione cliente / utente e un altro per utente su tutti i client. È necessario salvare i token di aggiornamento in una memoria a lungo termine e continuare a utilizzarli finché rimangono validi. Se l'applicazione richiede troppi token di aggiornamento, potrebbe rientrare in questi limiti, nel qual caso i token di aggiornamento più vecchi smetteranno di funzionare.
da questa pagina: https://developers.google.com/youtube/v3/guides/authentication#installed-apps
Questo è tratto dai documenti di YouTube (che trovo molto migliori di altri documenti api) ma penso che sia lo stesso in tutte le app di Google.
guarda questo:
I token di aggiornamento sono validi fino a quando l'utente non revoca l'accesso. Questo campo è presente solo se access_type = offline è incluso nella richiesta del codice di autorizzazione.
in https://developers.google.com/accounts/docs/OAuth2WebServer
Le regole sono cambiate su questo nel 2017, quindi la risposta migliore penso sia che dipende dal prodotto. Ad esempio, sull'API di Gmail, il token di aggiornamento Oauth 2.0 scade al momento della modifica della password. Vedi questo https://support.google.com/a/answer/6328616?hl=it
Prima configuravamo l'accesso API e generavamo token di aggiornamento quando configuravamo NUOVI utenti Gmail, quindi potevamo archiviare la loro posta (siamo tenuti a farlo per legge), ma ora non appena cambiano la password, il token di aggiornamento è revocato.
Forse per youtube, mappe, il token di aggiornamento è ancora veramente longevo, ma per l'API di Gmail, conta su un token breve.
Il concetto principale del token di aggiornamento è che è di lunga durata e non scade mai.
Il token di accesso ha un tempo di scadenza e scade, una volta scaduto possiamo andare per il token di aggiornamento, che verrà utilizzato ancora e ancora fino a quando l'utente non revoca dal suo account.
Leggi questo da: https://developers.google.com/identity/protocols/oauth2#expiration Devi scrivere il tuo codice per anticipare la possibilità che un token di aggiornamento concesso potrebbe non funzionare più. Un token di aggiornamento potrebbe smettere di funzionare per uno di questi motivi:
L'utente ha revocato l'accesso alla tua app. Il token di aggiornamento non è stato utilizzato per sei mesi. L'utente ha cambiato le password e il token di aggiornamento contiene gli ambiti di Gmail. L'account utente ha superato il numero massimo di token di aggiornamento concessi (live). Attualmente esiste un limite di 50 token di aggiornamento per account utente per client. Se viene raggiunto il limite, la creazione di un nuovo token di aggiornamento invalida automaticamente il token di aggiornamento più vecchio senza preavviso. Questo limite non si applica agli account di servizio.
Esiste anche un limite maggiore al numero totale di token di aggiornamento che un account utente o un account di servizio può avere su tutti i client. La maggior parte degli utenti normali non supererà questo limite ma potrebbe farlo l'account di prova di uno sviluppatore.
Ho effettuato ulteriori ricerche e sembra che il token di accesso di Google venga utilizzato per recuperare un token di aggiornamento, durante la prima richiesta "offline". Da questo punto in poi, il token di aggiornamento viene utilizzato per emettere un nuovo token di accesso. L'idea è che un token di accesso sia un token a breve termine, ma può essere rinnovato da un token di aggiornamento a lungo termine. Ciò elimina la necessità di dover richiedere la variabile "codice" dell'URL, che richiede un approccio a due endpoint e deve essere avviata, utilizzando una richiesta basata su referrer:
http://www.jensbits.com/2012/01/09/google-api-offline-access-using-oauth-2-0-refresh-token/
Alcuni servizi API REST come Dropbox, emettono token di accesso che durano per sempre, ma Google emette token di accesso a breve termine. PayPal utilizza un compromesso, in base al quale consente il recupero dei token di accesso senza l'applicazione del referrer URI. Ciò significa che i token di accesso possono essere recuperati senza dover fare clic su un collegamento per avviare il processo. La metodologia di Google significa che le routine API dovrebbero essere chiamate solo in base alla necessità di utilizzo. In sostanza, le chiamate vengono avviate tramite procedure basate su referrer. Ciò viene controllato mediante l'emissione di token di accesso di breve durata o token di accesso che devono essere aggiornati in una catena. Ciò richiede agli sviluppatori di pensare più attentamente a come dovrebbe fluire un sistema.