Publicado por Michael Winser, jefe de producción, Google Apps y Wesley Chun, representante de desarrolladores, Google Apps
La semana pasada, explicamos las expectativas y responsabilidades inherentes al acceso a los datos de un usuario de Google a través de Oauth 2.0. Hoy queremos anunciar que a partir del 5 de octubre de 2016 vamos a aumentar la seguridad de las cuentas para los usuarios empresariales de Gmail. Hoy entrará en vigencia una nueva política: a partir de esta fecha, a los usuarios en un dominio de Google Apps que cambien sus contraseñas se les anularán los token de Oauth 2.0 de las aplicaciones que tienen acceso a sus casillas de correo utilizando ámbitos de autorización basados en Gmail. Ten en cuenta que hoy los usuarios no notarán ningún cambio en especial y sus aplicaciones continuarán funcionando. Los tokens relacionados a Gmail pertenecientes a un usuario en particular solo quedarán invalidados a partir del momento en que este cambie su contraseña.

Los programadores deberían modificar sus aplicaciones para que puedan encargarse de códigos de error tales como HTTP 400 o 401, que son el resultado de tokens anulados y que solicitan a sus usuarios volver a repetir el proceso de OAuth para autorizar nuevamente a esas aplicaciones, de manera que puedan acceder otra vez a la casilla de correo del usuario (más abajo podrás encontrar más detalles). A fines del año pasado, anunciamos un cambio previsto y similar para nuestra política de seguridad, que afectó a un grupo más amplio de ámbitos de autorización. Luego de un tiempo, decidimos no implementar ese cambio para los clientes de las aplicaciones, y comenzamos a trabajar en una actualización de menor impacto, como lo explicamos más abajo.

¿Qué es un token anulado?

Un token de Oauth 2.0 anulado ya no proporcionará acceso a los recursos de un usuario. Cualquier intento de utilizar un token anulado en alguna llamada a una API dará como resultado un error. Las strings de los tokens que sigan existiendo ya no tendrán ningún valor, y deberían ser eliminadas. Se deben modificar las aplicaciones que accedan a las API de Google para que puedan encargarse de las llamadas erróneas a una API.

La anulación de un token no es una característica nueva. Los usuarios siempre pudieron anular el acceso a las aplicaciones en el control de seguridad, y los administradores de Google Apps pueden hacer lo mismo en la consola del administrador. A su vez, los tokens que no se utilizan por largos períodos de tiempo siempre han estado destinados a expirar o ser anulados. Este cambio en nuestra política de seguridad aumentará ciertamente la cantidad de tokens anulados que ven las aplicaciones, dado que en algunos casos el proceso se llevará a cabo en forma automática.

¿Cuáles son las API y ámbitos afectados por esto?

Hemos decidido limitar su aplicación solamente a ámbitos de correo y excluir tokens de scripts de aplicaciones para conseguir los beneficios de seguridad de este cambio de política, minimizar la confusión para los administradores y poner fin a la disrupción para el usuario final. Las aplicaciones que se instalen a través del Google Apps Marketplace tampoco estarán sujetas a la anulación del token. Una vez que este cambio haya sido implementado, las aplicaciones de correo de terceros como Apple Mail y Thunderbird (al igual que otras aplicaciones que usan varios ámbitos, que incluyen al menos un ámbito de correo) dejarán de tener acceso a los datos luego de un restablecimiento de contraseña, hasta que se haya otorgado un nuevo token de OAuth 2.0. Tu aplicación deberá detectar este caso en particular, notificar al usuario que tu aplicación ha perdido el acceso a los datos de su cuenta y solicitarle que vuelva a realizar el proceso de OAuth 2.0.

En este cambio de política también están incluidas las aplicaciones de correo para dispositivos móviles. Por ejemplo, los usuarios que utilizan la aplicación de correo nativa en iOS deberán volver a autorizarla con sus credenciales de cuenta de Google cuando cambien sus contraseñas. Este nuevo comportamiento en las aplicaciones de correo de terceros para plataformas móviles se pone en concordancia con el comportamiento actual de las aplicaciones de Gmail en iOS y Android, que también necesitan volver a autorizarlas luego de cambiar la contraseña.

¿Cómo puedo saber si mi token fue anulado?

Tanto los tokens de acceso de corta duración como los de larga duración serán anulados cuando un usuario cambie su contraseña. La utilización de un token de acceso anulado para acceder a una API o para generar un nuevo token de acceso dará como resultado un error HTTP 400 o 401. Si tu aplicación utiliza una biblioteca para acceder a la API o para controlar el proceso de OAuth, seguramente estos errores aparecerán como excepciones. En la documentación de la biblioteca, podrás encontrar información sobre cómo interceptar estas excepciones. NOTA: debido a que los errores HTTP 400 pueden estar causados por una gran variedad de motivos, debes tener en cuenta que la carga de un tipo 400 que haya sido producto de un token anulado, puede ser similar a: 

{
  "error_description": "Token has been revoked.", 
  "error": "invalid_grant"
}

¿Cómo puede mi aplicación controlar los tokens anulados?

Este cambio hace hincapié en que la anulación de un token debería ser considerada una condición normal, no un caso erróneo. Tu aplicación debería esperar y detectar a la condición, y tu IU debería estar optimizada para ser capaz de restaurar un token.

Para asegurarte de que tu aplicación funcione correctamente, te recomendamos lo siguiente:

  • Agrega código que se encargue de controlar los errores entre las llamadas a una API y actualizaciones de token que puedan detectar los token anulados.
  • Luego de detectar un token anulado, deshabilita las funciones de la aplicación que dependan del acceso a las API de Google, hasta que el usuario pueda volver a autorizar tu aplicación. Por ejemplo, suspende cualquier tarea recurrente en segundo plano que sincronice datos con alguna API de Google que pudiera estar afectada.
  • Notifica al usuario que el acceso ha sido anulado y pídele que vuelva a autorizar el acceso a sus recursos.
    • Si tu aplicación interactúa directamente con el usuario, deberás pedirle a este que vuelva a autorizar, por ejemplo, enviarle un correo electrónico al usuario y/o mostrarle un mensaje de alerta la próxima vez que inicie tu aplicación.
    • Sin embargo, si tu aplicación se ejecuta de forma independiente con respecto al usuario, por ejemplo, una aplicación de segundo plano que utilice la API de Gmail, deberás darle aviso al usuario a través de un correo electrónico u otro tipo de mecanismo.
    • Asegúrate de brindar una IU simple para volver a autorizar el acceso. Evita que los usuarios tengan que explorar tu aplicación para encontrar la configuración original.
    • Ten en cuenta que los token anulados darán como resultado mensajes de error similares, sin importar cómo haya sido anulado cada uno. El mensaje que envíes no debería dar por sentado que el token fue anulado debido a un cambio de contraseña.

Si tu aplicación utiliza la autorización progresiva juntar varios ámbitos dentro del mismo token, deberías monitorear qué funcionalidades y ámbitos han sido habilitadas por un usuario en particular. El resultado final es que si tu aplicación solicitó y obtuvo autorización para varios ámbitos y por lo menos uno de estos es un ámbito de correo, entonces ese token será anulado; significa que deberás pedirle al usuario que vuelva a conceder autorización para todos los ámbitos que originalmente estaban autorizados.

Muchas aplicaciones usan los token para realizar llamadas a API en segundo plano o de servidor a servidor. Los usuarios confían en que esta actividad en segundo plano funciona sin problemas. Dado que este cambio de política también afecta a aquellas aplicaciones, esto eleva la importancia que tienen las notificaciones para solicitar una nueva autorización.

¿Para cuándo está programado este cambio?

En resumen, las aplicaciones que estén adecuadamente configuradas deberían, por lo general, ser capaces de controlar a los token anulados, sin importar si su condición es producto de una caducidad, una inexistencia o un anulamiento. Alentamos a los programadores a realizar los cambios necesarios para proporcionarle a los usuarios la mejor experiencia posible. Este cambio de política entrará en vigencia el 5 de octubre de 2016.

Consulta este artículo del Centro de ayuda y las preguntas frecuentes para obtener más información y la lista completa de los ámbitos de correo. De ahora en adelante se comunicará por adelantado cuando sea necesario agregar ámbitos adicionales a la política. Informaremos a medida que los detalles estén disponibles.