¿Los tokens de actualización de Google caducan?

He usado el token de actualización varias veces en solo un breve período de tiempo para realizar pruebas, pero me pregunto si el token de actualización de Google caducará. O puedo llamar al mismo token de actualización para obtener otro token de acceso una y otra vez en un período prolongado (una semana o incluso meses).

El servidor Google Auth emitido Refresh tokens nunca caduca; ese es el objective de los tokens de actualización. El token de actualización caducará (o debería decir que no está autorizado) cuando el usuario cancele el acceso a su aplicación.

Consulte este documento que establece claramente la función de los tokens de actualización.

En lugar de emitir un token de larga duración (normalmente bueno por un año o duración ilimitada), el servidor puede emitir un token de acceso de corta duración y un token de actualización de larga duración. En resumen, puede usar tokens de actualización una y otra vez hasta que el usuario que autorizó el acceso revoca el acceso a su aplicación.

Este es un hilo muy confuso. La primera respuesta parece ser correcta, pero en realidad no cita nada autorizado de Google.

La respuesta más definitiva que encontré es en realidad en el patio de recreo del desarrollador donde obtienes el token. El paso 2 tiene una nota en la parte inferior que dice:

“Nota: OAuth Playground no almacena tokens de actualización, pero como los tokens de actualización nunca caducan, el usuario debe ir a la página de acceso autorizado de su cuenta de Google si desea revocarlos manualmente”.

https://developers.google.com/oauthplayground/

No creo que eso sea completamente cierto:

Tenga en cuenta que hay límites en la cantidad de tokens de actualización que se emitirán; un límite por combinación de cliente / usuario y otro por usuario en todos los clientes. Debería guardar los tokens de actualización en el almacenamiento a largo plazo y continuar usándolos mientras sigan siendo válidos. Si su aplicación solicita demasiados tokens de actualización, puede llegar a estos límites, en cuyo caso los tokens de actualización más antiguos dejarán de funcionar.

desde esta página: https://developers.google.com/youtube/v3/guides/authentication#installed-apps

Eso es de los documentos de youTube (que me parece que es mucho mejor que otros documentos de API) pero creo que es el mismo en todas las aplicaciones de Google.

mira esto:

Los tokens de actualización son válidos hasta que el usuario cancele el acceso. Este campo solo está presente si access_type = offline está incluido en la solicitud del código de autorización.

en https://developers.google.com/accounts/docs/OAuth2WebServer

Las reglas han cambiado en este momento en 2017, así que la mejor respuesta, creo, es que depende del producto. Por ejemplo, en la API de Gmail, el token de actualización de Oauth 2.0 caduca al cambiar la contraseña. Consulte esto https://support.google.com/a/answer/6328616?hl=es

Solíamos configurar el acceso a API por adelantado y generar tokens de actualización cuando configuramos NUEVOS usuarios de Gmail, y luego podíamos archivar su correo (debemos hacerlo por ley), pero ahora tan pronto como cambian su contraseña, el token de actualización es revocado

Quizás para youtube, maps, el token de actualización todavía es realmente longevo, pero para la API de Gmail, cuente con un token corto.

El concepto principal de token de actualización es que es duradero y nunca caduca.

El token de acceso tiene un tiempo de caducidad y caduca, una vez que caduca podemos ir al token de actualización, que se utilizará una y otra vez hasta que el usuario cancele su cuenta.

He realizado más investigaciones y parece que el token de acceso de Google se usa para recuperar un token de actualización durante la primera solicitud ‘sin conexión’. Desde este punto en adelante, el token de actualización se usa para emitir un nuevo token de acceso. La idea es que un token de acceso es un token de corto plazo, pero puede renovarse con un token de actualización a largo plazo. Esto elimina la necesidad de tener que solicitar la variable URL ‘código’, que requiere un enfoque de dos puntos finales y debe iniciarse, utilizando una solicitud basada en referencia:

http://www.jensbits.com/2012/01/09/google-api-offline-access-using-oauth-2-0-refresh-token/

Algunos, los servicios REST API como Dropbox, emiten tokens de acceso que duran para siempre, pero Google emite tokens de acceso a corto plazo. PayPal utiliza un compromiso, por el cual permite que los tokens de acceso sean recuperados sin la aplicación de referencia de URI. Esto significa que los tokens de acceso se pueden recuperar sin tener que hacer clic en un enlace para iniciar el proceso. La metodología de Google significa que las rutinas de API solo deben invocarse según la necesidad de uso. Esencialmente, las llamadas se inician a través de procedimientos basados ​​en referencias. Esto se controla emitiendo tokens de acceso de corta duración o tokens de acceso que se deben renovar en una cadena. Esto requiere que los desarrolladores piensen más cuidadosamente sobre cómo debería fluir un sistema.