¿Caducan los tokens de actualización de Google?


108

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


¿Estás usando ruby ​​o tienes una muestra de código para eso?
Thufir

Respuestas:


146

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.


6
La parte de "bueno para un año" no lo deja tan claro como sugiere; pero como no parece causar problemas en la práctica, asumo que el token de actualización es siempre verde.
mahemoff

54
Caducidad del token Debe escribir su código para anticipar la posibilidad de que un token otorgado ya no funcione. Un token puede dejar de funcionar por una de estas razones: El usuario ha revocado el acceso. El token no se ha utilizado durante seis meses. La cuenta de usuario ha superado un cierto número de solicitudes de token. Actualmente, existe un límite de 25 tokens por cuenta de usuario de Google. Si una cuenta de usuario tiene 25 tokens válidos, la siguiente solicitud de autenticación tiene éxito, pero invalida silenciosamente el token pendiente más antiguo sin ninguna advertencia visible para el usuario. (de developers.google.com/accounts/docs/OAuth2 )
bazik

17
El token de actualización 'de larga duración' es algo diferente a 'nunca caduca'.
Kapé

1
Entonces, ¿cómo puede su código verificar si su token de actualización sigue siendo válido?
SsjCosty

3
@Shadow Si el token de actualización rara vez caduca, como se sugiere, ¿por qué Google simplemente no emite un token de acceso que no caduca, en primer lugar? Según tengo entendido, el token de acceso que se emite mediante oAuth 2.0 se puede utilizar para solicitar un token de actualización. ¿Por qué no tener un token de acceso permanente y eliminar la llamada adicional para el token de actualización?
Charles Robertson

62

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/


2
la mejor respuesta aquí - por qué nadie ha votado a favor es increíble - muchas gracias - trate los tokens de actualización como si nunca caducasen; sin embargo, al iniciar sesión, verifique si hay uno nuevo en caso de que el usuario revoque el token de actualización, en este caso, Google proporcionará un nuevo token de actualización al
iniciar sesión,

14

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.



5

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.


Parece que se hizo oficial el 5 de octubre de 2016. developers.googleblog.com/2016/09/…
TonyE

2

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.


0

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.


-2

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.