Cómo funciona la autorización del usuario

Si eres nuevo o no estás familiarizado con Google Identity Services o la autorización, primero lee la Descripción general.

Google ofrece una biblioteca de JavaScript que incluye funciones de autorización para ayudarte a administrar alcances, 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.

Alcances de solo autenticación

Solo se usan varios permisos 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 acceso de los usuarios satisfacen tus necesidades. En la mayoría de los casos, este es el método más simple y sencillo disponible para la autenticación del usuario.

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 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 de forma segura a las APIs de Google y acceder a los datos del usuario.
  • El código de autorización es un código temporal que emite Google para identificar de forma segura a los 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 larga duración por usuario 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 alcance restringe los tokens a una cantidad definida y limitada de datos del usuario. Consulta Permisos de OAuth 2.0 para las APIs de Google si quieres obtener más información.
  • El modo de ventana 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 luego es responsable de enviar el código de Auth a tu plataforma. Tú decides cómo hacerlo.
  • 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; el segundo redireccionamiento de Google al extremo del código de autorización de la plataforma incluye el código.

Google establece la duración del token como entidad emisora. Debido a diversos factores, la duración exacta puede variar.

Flujos de OAuth 2.0

Se analizan dos flujos: el implícito y el de autorización. Ambas muestran un token de acceso adecuado para usar con las APIs 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 tu plataforma realice acciones asíncronas con mayor facilidad, como enviar un recordatorio por SMS de una próxima reunión que se programó para el último minuto. En Elegir un modelo de autorización, se explican con más detalle las diferencias entre los dos flujos.

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 para permitir que tu app web en el navegador obtenga de manera rápida y fácil un token de acceso de Google que es necesario para llamar a las APIs de Google
  • Iniciar el flujo de 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 permisos.
  2. Google muestra un cuadro de diálogo de consentimiento al usuario y, si es necesario, primero permite que el usuario acceda a su Cuenta de Google.
  3. El usuario aprueba de forma individual cada alcance solicitado.

Cada flujo luego 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 tu app sobre el resultado del consentimiento y mostrar un token de acceso para cualquier alcance aprobado.

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 al extremo de código de autorización de tu plataforma.
    • En el modo de ventana emergente, el código se devuelve al controlador de devolución de llamada de tu app integrada en el navegador, sin que los usuarios tengan que salir de tu sitio web.
  • A partir del Paso 4: Controla la respuesta del servidor de OAuth 2.0, tu plataforma de backend completa un intercambio de servidor a servidor con Google, lo que, en última instancia, hace que se muestre 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 consentimiento para que tu app acceda a los permisos solicitados. Para ello, Google muestra un cuadro de diálogo de consentimiento durante el paso 2 y registra el resultado en myaccount.google.com/permissions.

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

En la Figura 1, se muestra el cuadro de diálogo de consentimiento para un solo alcance. 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 cuadro de diálogo de consentimiento para múltiples alcances. Cuando se solicita más de un alcance, se necesitan casillas de verificación individuales para permitir que el usuario apruebe o rechace cada alcance.

En el cuadro de diálogo de consentimiento del usuario con los botones Cancelar o Continuar, y varios alcances, cada uno tiene un selector de casillas de verificación.

Figura 2: Cuadro de diálogo de consentimiento del usuario con varios alcances

Cuentas de usuario

Se requiere una Cuenta de Google para registrar el consentimiento y emitir un token de acceso. Antes de esto, los usuarios individuales se deben haber autenticado en Google mediante el acceso a una Cuenta de Google.

Si bien no es un requisito, se recomienda que se use Acceder con Google para el registro y el acceso a tu app web o plataforma de backend. Esto reduce la fricción del usuario, ya que minimiza la cantidad de pasos necesarios y, de forma opcional, te permite asociar fácilmente tokens de acceso con cuentas individuales en tu plataforma.

Por ejemplo, cuando se usa Acceder con Google, se establece una sesión activa de una Cuenta de Google, lo que evita la necesidad de solicitarle más adelante al usuario que acceda a una Cuenta de Google cuando realiza una solicitud de autorización. Si eliges autenticar a los usuarios en tu app por otros medios, como nombres de usuario y contraseñas, o bien otros proveedores de identidad, de todos modos deberán acceder 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 que Google omita la visualización de un selector de cuentas, lo que ahorra un paso a los usuarios. La credencial del token de ID que muestra Acceder con Google contiene la dirección de correo electrónico del usuario.

Las aplicaciones web que se ejecutan únicamente en el navegador pueden depender únicamente de Google para la autenticación del usuario y 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 la 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 y administrar un sistema de cuentas de usuario es exclusivo de tu plataforma y no se analiza con más detalle.

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

De manera opcional, tu app web o plataforma puede 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 tu 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 las 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, recomendamos usar la biblioteca de Google Identity Services para reducir el tiempo y esfuerzo de desarrollo y minimizar los riesgos de seguridad, como los que se describen en la Práctica recomendada actual de seguridad de OAuth 2.0.