¿Caducan los tokens de actualización de Google?

He utilizado el token de actualización varias veces en un breve período de tiempo con fines de prueba, pero me pregunto si los tokens de actualización de Google alguna vez caducan. ¿Puedo usar el mismo token de actualización para obtener otro token de acceso una y otra vez durante un período prolongado (una semana o incluso meses)?

Los tokens de actualización emitidos por el servidor de Google Auth nunca caducan; ese es el objetivo de los tokens de actualización. El token de actualización caducará (o debería decir que no estará autorizado) cuando el usuario revoque el acceso a su aplicación.

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

En lugar de emitir un token de larga duración (normalmente válido por un año o de por vida 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 revoque 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é se encuentra en el patio de juegos 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 existen 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. Debe guardar los tokens de actualización en un almacenamiento a largo plazo y continuar usándolos mientras sigan siendo válidos. Si su aplicación solicita demasiados tokens de actualización, es posible que alcance estos límites, en cuyo caso los tokens de actualización más antiguos dejarán de funcionar.

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

Eso es de los documentos de YouTube (que encuentro mucho mejor que otros documentos de API) pero creo que es lo mismo en todas las aplicaciones de Google.

mira esto:

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

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

Las reglas han cambiado sobre esto en algún momento de 2017, por lo que creo que la mejor respuesta 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. Mira esto https://support.google.com/a/answer/6328616?hl=es

Solíamos configurar el acceso a la API de antemano y generar tokens de actualización cuando configuramos NUEVOS usuarios de gmail, y luego podíamos archivar su correo (estamos obligados a hacerlo por ley), pero ahora, tan pronto como cambien su contraseña, el token de actualización está revocado.

Quizás para youtube, mapas, el token de actualización todavía es realmente de larga duración, pero para gmail api, cuente con un token corto.

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

El token de acceso tiene un tiempo de caducidad y caduca, una vez caduca podemos ir por el token de refresco, que será usado una y otra vez hasta que el usuario revoca de su cuenta.

Lea esto en: https://developers.google.com/identity/protocols/oauth2#expiration Debe escribir su código para anticipar la posibilidad de que un token de actualización otorgado ya no funcione. Un token de actualización puede dejar de funcionar por uno de estos motivos:

El usuario ha revocado el acceso a su aplicación. El token de actualización no se ha utilizado durante seis meses. El usuario cambió las contraseñas y el token de actualización contiene los alcances de Gmail. La cuenta de usuario ha superado el número máximo de tokens de actualización concedidos (activos). Actualmente hay un límite de 50 tokens de actualización por cuenta de usuario y cliente. Si se alcanza el límite, la creación de un nuevo token de actualización invalida automáticamente el token de actualización más antiguo sin previo aviso. Este límite no se aplica a las cuentas de servicio.

También hay un límite mayor en el número total de tokens de actualización que una cuenta de usuario o cuenta de servicio puede tener en todos los clientes. La mayoría de los usuarios normales no superarán este límite, pero la cuenta de prueba de un desarrollador podría hacerlo.

He investigado un poco más 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". A partir de este punto, el token de actualización se utiliza para emitir un nuevo token de acceso. La idea es que un token de acceso sea un token a corto plazo, pero se puede renovar con un token de actualización a largo plazo. Esto elimina la necesidad de tener que solicitar la variable de 'código' de URL, que requiere un enfoque de dos puntos finales y debe iniciarse mediante una solicitud basada en referencias:

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

Algunos, los servicios de API REST como Dropbox, emiten tokens de acceso que duran para siempre, pero Google emite tokens de acceso a corto plazo. PayPal utiliza un compromiso, mediante el cual permite que los tokens de acceso se recuperen 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 sea necesario. Básicamente, las llamadas se inician mediante procedimientos basados ​​en referencias. Esto se controla mediante la emisión de tokens de acceso de corta duración o tokens de acceso que deben actualizarse en una cadena. Esto requiere que los desarrolladores piensen más detenidamente sobre cómo debería fluir un sistema.