Advertencia: Estos datos se proporcionan conforme a la Política de Datos del Usuario de Google. Revise y satisfaga la política. De lo contrario, el proyecto o la cuenta podrían suspenderse.

Cómo funciona la autorización del usuario

Si eres nuevo o no estás familiarizado con los servicios de identidad o la autorización de Google, lee la Descripción general.

Google ofrece una biblioteca de JavaScript que incluye funciones de autorización para ayudarte a administrar los permisos, obtener el consentimiento del usuario y trabajar de manera más sencilla con los flujos estándar de OAuth 2.0. Tu aplicación web, que se ejecuta en el navegador del usuario, usa esta biblioteca para administrar el flujo implícito de OAuth 2.0 o para iniciar el flujo de código de autorización que finaliza en tu plataforma de backend.

Permisos de autenticación únicamente

Solo se usan varios alcances para la autenticación del usuario: email, profile y openid. Si tu app solo usa estos permisos, considera si un token de ID de JWT y el acceso con Google para el registro y acceso de los usuarios satisfacen tus necesidades. En la mayoría de los casos, este es el método más simple y directo disponible para la autenticación de usuarios.

Términos y conceptos clave

Estas guías suponen que tienes conocimientos básicos de los conceptos de OAuth 2.0 y los estándares de IETF, como RFC6749. Los siguientes términos se usan en todas las guías de autorización:

  • El token de acceso es una credencial de corta duración por usuario emitida por Google que se usa para llamar a las API de Google y acceder a los datos del usuario de forma segura.
  • El código de autorización es un código temporal que emite Google para identificar de forma segura a los usuarios que acceden a su Cuenta de Google desde un navegador. Tu plataforma de backend cambia este código por tokens de acceso y actualización.
  • El token de actualización es una credencial de larga duración por usuario emitida por Google que se almacena de forma segura en tu plataforma y se puede usar para obtener un nuevo token de acceso válido incluso cuando el usuario no está presente.
  • El alcance restringe los tokens a una cantidad definida y limitada de datos del usuario. Consulta Alcances de OAuth 2.0 para las API de Google a fin de obtener más información.
  • El modo emergente es un flujo de código de autorización basado en una devolución de llamada de JavaScript que se ejecuta en el navegador del usuario. Google invoca el controlador de devolución de llamada, que luego es responsable de enviar el código de Auth a tu plataforma. La forma de hacerlo depende de ti.
  • El modo de redireccionamiento es un flujo de código de autorización basado en redireccionamientos HTTP. Primero, se redirecciona al usuario-agente a Google, un segundo redireccionamiento de Google a tu extremo del código de autorización de la plataforma.

Google define la vida útil de los tokens como la entidad emisora. Debido a varios factores, la duración exacta puede variar.

Flujos de OAuth 2.0

Se analizan dos flujos, el código implícito y el de autorización. Ambos muestran un token de acceso adecuado para usar con las API de Google.

Se recomienda el flujo de código de autorización, ya que ofrece una mayor seguridad del usuario. Este flujo también muestra un token de actualización que se puede usar para obtener tokens de acceso sin que el usuario esté presente, lo que permite que la plataforma realice acciones asíncronas con mayor facilidad, como enviar un recordatorio por SMS de una reunión próxima que se programó a último momento. En Elige un modelo de autorización, se explican las diferencias entre los dos flujos con más detalle.

La biblioteca de JavaScript de los servicios de identidad de Google sigue el estándar OAuth 2.0 para lo siguiente:

  • Administrar el flujo implícito a fin de permitir que tu app web en el navegador obtenga, de forma rápida y fácil, un token de acceso de Google necesario para llamar a las API de Google
  • iniciar el flujo del código de autorización desde el navegador del usuario

Pasos comunes

El flujo de código implícito y de autorización comienza de la misma manera:

  1. Tu app solicita acceso a uno o más permisos.
  2. Google mostrará un cuadro de diálogo de consentimiento al usuario y, si es necesario, primero accederá a su Cuenta de Google.
  3. El usuario aprueba individualmente cada alcance solicitado.

Cada flujo termina con pasos diferentes.

Cuando se usa el flujo implícito

  • Google usa un controlador de devolución de llamada a fin de notificar a tu app sobre el resultado del consentimiento y mostrar un token de acceso para los permisos aprobados.

Cuando usas el flujo de código de Auth

  • Google responde con un código de autorización por usuario:
    • En el modo de redireccionamiento, el código se devuelve al extremo del código de autorización de tu plataforma.
    • En el modo emergente, el código se devuelve al controlador de devolución de llamada de la app en el navegador, sin que los usuarios necesiten salir de tu sitio web.
  • A partir del paso 4: Controla la respuesta del servidor OAuth 2.0, la plataforma de backend completa un intercambio de servidor a servidor con Google, lo que, en última instancia, genera un token de actualización por usuario y un token de acceso a tu plataforma.

Antes de obtener un token de acceso, los usuarios individuales deben otorgar su consentimiento para que la app pueda acceder a los permisos solicitados. Para ello, Google muestra un diálogo de consentimiento durante el Paso 2 anterior y registra el resultado en myaccount.google.com/permissions.

Se muestran el nombre de la app, el logotipo, la política de privacidad, las condiciones del servicio y los permisos solicitados al usuario junto con la opción de aprobar o cancelar la solicitud.

En la figura 1, se muestra el diálogo de consentimiento para un solo alcance. Cuando se solicita un solo alcance, no se necesitan casillas de verificación para aprobar o denegar un alcance.

Diálogo de consentimiento del usuario con los botones Cancelar o Continuar y un solo alcance, no se muestran casillas de verificación

Figura 1: Diálogo de consentimiento del usuario con un solo alcance

En la Figura 2, se muestra el diálogo de consentimiento para varios alcances. Cuando se solicitan más de un alcance, se necesitan casillas de verificación individuales para permitir que el usuario apruebe o rechace cada alcance.

Diálogo de consentimiento del usuario con los botones Cancelar o Continuar y varios alcances; cada alcance tiene un selector de casilla de verificación.

Figura 2: Diálogo de consentimiento del usuario con varios alcances.

Cuentas de usuario

Se necesita una Cuenta de Google para registrar el consentimiento y emitir un token de acceso. Antes de eso, los usuarios individuales deben acceder a una Cuenta de Google para autenticarse en Google.

Si bien no es un requisito, se recomienda acceder con Google para registrarte y acceder a tu aplicación web o plataforma de backend. Esto reduce la fricción del usuario mediante la minimización de la cantidad de pasos necesarios y, de forma opcional, te permite asociar con facilidad los tokens de acceso con cuentas individuales en tu plataforma.

Por ejemplo, cuando se usa Acceder con Google, se establece una sesión activa de la Cuenta de Google, lo que evita la necesidad de solicitarle al usuario que acceda a una Cuenta de Google cuando realice una solicitud de autorización. Si eliges autenticar usuarios en tu app por otros medios, como nombre de usuario y contraseña, o algún otro proveedor de identidad, de todas formas se les pedirá que accedan primero a una Cuenta de Google para obtener su consentimiento.

Agregar una sugerencia durante la inicialización de la autorización (por lo general, la dirección de correo electrónico de la Cuenta de Google del usuario) permite a Google omitir la visualización del selector de cuentas, lo que ahorra a los usuarios un paso. La credencial del token de ID que muestra el acceso con Google contiene la dirección de correo electrónico del usuario.

Las aplicaciones web que se ejecutan solo en el navegador pueden depender únicamente de Google para la autenticación de usuarios y pueden elegir no implementar un sistema de administración de cuentas de usuario. En esta situación, conocida como flujo implícito, no es necesario asociar un token de actualización a una cuenta de usuario y al almacenamiento seguro de administración.

Como alternativa, el flujo de código de autorización requiere un sistema de cuenta de usuario. Los tokens de actualización por usuario deben estar asociados con una cuenta individual en tu plataforma de backend y almacenarse para su uso posterior. La forma de implementar, trabajar con y administrar un sistema de cuenta de usuario es exclusiva de tu plataforma y no se analiza en más detalle.

Los usuarios pueden ver o revocar el consentimiento en cualquier momento desde la configuración de su Cuenta de Google.

De manera opcional, tu app web o plataforma pueden llamar a google.accounts.oauth2.revoke para revocar tokens y quitar el consentimiento del usuario, lo que resulta útil cuando un usuario borra su cuenta de la plataforma.

Otras opciones de autorización

Como alternativa, los navegadores pueden obtener tokens de acceso mediante el flujo implícito llamando directamente a los extremos de OAuth 2.0 de Google como se describe en OAuth 2.0 para aplicaciones web del cliente.

Del mismo modo, para el flujo de código de autorización, puedes optar por implementar tus propios métodos y seguir los pasos que se describen en Cómo usar OAuth 2.0 para aplicaciones de servidor web.

En ambos casos, te recomendamos usar la biblioteca de los Servicios de identidad de Google para reducir el tiempo y el esfuerzo de desarrollo y minimizar los riesgos de seguridad, como se describen en la Práctica actual de seguridad de OAuth 2.0.