Cómo funciona la autorización del usuario

Si eres nuevo o no estás familiarizado con los servicios o la autorización de Google Identity, comienza por leer la Descripción general.

Google ofrece una biblioteca de JavaScript que incluye funciones de autorización para administrar los permisos, obtener el consentimiento del usuario y trabajar con mayor facilidad 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 solo de autenticación

Se usan varios alcances solo para la autenticación de usuarios: email, profile y openid. Si tu app solo usa estos permisos, considera si un token de ID de JWT y Acceder con Google para el registro y el 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

En estas guías, se supone que tienes un conocimiento básico de los conceptos de OAuth 2.0 y estándares de IETF, como RFC6749. Los siguientes términos se usan en las guías de autorización:

  • El token de acceso es una credencial de corta duración por usuario que emite Google y que se usa para llamar de forma segura a las API de Google y acceder a los datos del usuario.
  • El código de autorización es un código temporal emitido por Google para identificar de forma segura usuarios individuales que acceden a su Cuenta de Google desde un navegador. Tu plataforma de backend intercambia este código por tokens de acceso y actualización.
  • El token de actualización es una credencial de usuario de larga duración que emite Google, que se almacena de forma segura en tu plataforma y que se puede usar para obtener un token de acceso nuevo y válido incluso cuando el usuario no está presente.
  • El permiso restringe los tokens a una cantidad definida y limitada de datos del usuario. Consulta los permisos 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 tu controlador de devolución de llamada, que es el responsable de enviar el código de Auth a tu plataforma. La forma en que lo haces depende de ti.
  • El modo de redireccionamiento es un flujo de código de autorización basado en redireccionamientos HTTP. El usuario-agente se redirecciona primero a Google, mientras que un segundo redireccionamiento de Google al extremo del código de autorización de la plataforma incluye el código.

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: implícito y código de autorización. Ambos muestran un token de acceso adecuado para su uso 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 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 aplicación web en el navegador obtenga un token de acceso de Google de forma rápida y fácil, lo que es necesario para llamar a las API de Google
  • iniciar el flujo del código de autorización desde el navegador del usuario.

Pasos comunes

Tanto el flujo de código implícito como el de autorización comienzan de la misma manera:

  1. Tu app solicita acceso a uno o más alcances.
  2. Google le muestra al usuario un diálogo de consentimiento y, si es necesario, primero debe acceder a su Cuenta de Google.
  3. El usuario aprueba de forma individual cada alcance solicitado.

Luego, cada flujo finaliza con diferentes pasos.

Cuando se usa el flujo implícito

  • Google usa un controlador de devolución de llamada a fin de notificar a la app 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 muestra en el extremo del código de autorización de la plataforma.
    • En el modo emergente, el código se muestra en el controlador de devolución de llamada de la app en el navegador, sin que los usuarios necesiten abandonar tu sitio web.
  • A partir del paso 4: Maneja la respuesta del servidor de OAuth 2.0, tu plataforma de backend completa un intercambio de servidor a servidor con Google, lo que da como resultado un token de actualización por usuario y un token de acceso que se muestra en tu plataforma.

Antes de obtener un token de acceso, los usuarios deben otorgar el consentimiento para que tu app acceda 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.

El nombre de tu app, el logotipo, la política de privacidad, las Condiciones del Servicio y los alcances solicitados se muestran 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 único permiso. Cuando se solicita un solo alcance, no se necesitan casillas de verificación para aprobar o rechazar un alcance.

Diálogo de consentimiento del usuario con 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 permisos. 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 botones Cancelar o Continuar y varios permisos, cada uno con 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 deben autenticarse en Google accediendo a una Cuenta de Google.

Si bien no es un requisito, se recomienda usar Acceder con Google para el registro y el acceso a tu aplicación web o a la plataforma de backend. Hacerlo reduce la fricción del usuario mediante la minimización de la cantidad de pasos necesarios y, de manera opcional, te permite asociar fácilmente tokens de acceso con cuentas individuales en tu plataforma.

Por ejemplo, cuando usas 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 bien otros proveedores de identidad, de todos modos se les solicitará que primero accedan a una Cuenta de Google para obtener su consentimiento.

Agregar una sugerencia de acceso 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 Acceder con Google contiene la dirección de correo electrónico del usuario.

Es posible que las apps web que se ejecutan solo en el navegador dependan únicamente de Google para la autenticación de usuarios y decidan 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 usarlos más tarde. Cómo implementar, trabajar y administrar un sistema de cuenta de usuario es único para tu plataforma y no se analiza con 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 o plataforma web puede llamar a google.accounts.oauth2.revoke para revocar tokens y quitar el consentimiento del usuario, lo que es ú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.

De manera similar, para el flujo de código de autorización, puedes elegir implementar tus propios métodos y seguir los pasos descritos en Usa OAuth 2.0 para aplicaciones de servidor web.

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