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.

Elige un modelo de autorización de usuario

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Esta guía te ayuda a elegir entre usar la biblioteca de los servicios de identidad de Google para la autorización del usuario o implementar tu propia biblioteca de JavaScript. Te ayuda a decidir qué flujo de autorización de OAuth 2.0 es el mejor para tu aplicación web.

Antes de leer esta guía, se supone que estás familiarizado con los términos y conceptos descritos en las guías de descripción general y cómo funciona la autorización de usuario.

La biblioteca de GIS se ejecuta en estos navegadores compatibles en el dispositivo del usuario. No está diseñado para usarse con frameworks de JavaScript del servidor, como Node.js, sino la biblioteca cliente de Node.js de Google.

Esta guía solo abarca los temas sobre autorización y uso compartido de datos. No revisa la autenticación de usuarios. En su lugar, consulta Acceder con Google y la guía Migra desde el Acceso con Google para el acceso y el acceso de los usuarios.

Cómo decidir si la biblioteca de GIS es adecuada para ti

Debes elegir si usar la biblioteca de Google o crear una propia que se adapte a tus necesidades. Descripción general de las características y funcionalidades:

  • La biblioteca JavaScript de los servicios de identidad de Google implementa lo siguiente:
    • Flujos de consentimiento basados en ventanas emergentes para minimizar los redireccionamientos, lo que permite que los usuarios permanezcan en tu sitio durante todo el proceso de autorización.
    • Funciones de seguridad, como la falsificación de solicitudes entre sitios (CRSF)
    • Métodos auxiliares para solicitar permisos individuales y confirmar el consentimiento del usuario.
    • Vínculos de documentación y manejo de errores sencillos para que los ingenieros los usen durante el desarrollo y los que visiten el sitio después.
  • Cuando realices implementaciones sin la biblioteca de servicios de identidad, serás responsable de lo siguiente:
    • Administrar solicitudes y respuestas con los extremos de OAuth 2.0 de Google, incluidos los redireccionamientos
    • Optimizar la experiencia del usuario
    • Implementación de funciones de seguridad para validar solicitudes y respuestas, y para evitar el CSRF.
    • Métodos para confirmar que un usuario otorgó su consentimiento para cualquier permiso solicitado.
    • Administración de códigos de error de OAuth 2.0, creación de mensajes legibles y vínculos a ayuda del usuario

En resumen, Google ofrece la biblioteca de GIS para ayudarte a implementar de forma rápida y segura un cliente de OAuth 2.0 y optimizar la experiencia de autorización del usuario.

Elige un flujo de autorización

Deberás elegir uno de dos flujos de autorización de OAuth 2.0: código implícito o de autorización, independientemente de si decides usar la biblioteca de JavaScript de los servicios de identidad de Google o crear tu propia biblioteca.

Ambos flujos generan un token de acceso que se puede usar para llamar a las API de Google.

Las principales diferencias entre los dos flujos son las siguientes:

  • la cantidad de acciones de los usuarios
  • Si tu app llamará a las API de Google sin la presencia del usuario.
  • si se necesita una plataforma de backend para alojar un extremo y almacenar tokens de actualización por usuario para cuentas de usuario individuales
  • niveles más altos o más bajos de seguridad del usuario.

Cuando se comparan los flujos y se evalúan los requisitos de seguridad, un factor que debes considerar es que el nivel de seguridad del usuario varía según los permisos que elijas. Por ejemplo, ver las invitaciones de calendario como de solo lectura se puede considerar menos riesgoso que usar un alcance de lectura y escritura para editar archivos en Drive.

Comparación del flujo de OAuth 2.0

Flujo implícito Flujo de código de autorización
Se requiere el consentimiento del usuario Para cada solicitud de token, incluido el reemplazo de tokens vencidos. Solo para la primera solicitud de token.
El usuario debe estar presente No, admite el uso sin conexión.
Seguridad del usuario Menos La mayoría tiene autenticación de clientes y evita los riesgos de manejo de tokens en el navegador.
Se emitió el token de acceso
Se emitió un token de actualización No
Se requiere un navegador compatible
Token de acceso que se usa para llamar a las API de Google solo desde una aplicación web que se ejecuta en el navegador del usuario ya sea desde un servidor que se ejecuta en la plataforma backend o desde una app web que se ejecuta en el navegador del usuario.
Requiere una plataforma de backend No Sí, para el hosting y el almacenamiento de extremos.
Se necesita almacenamiento seguro No Sí, para el almacenamiento de tokens de actualización.
Requiere el hosting de un extremo de código de autorización No Sí, para recibir códigos de autorización de Google.
Comportamiento de vencimiento de tokens de acceso Se requiere un gesto del usuario, como presionar un botón o hacer clic en un vínculo, para solicitar y obtener un nuevo token de acceso válido. Después de una solicitud inicial del usuario, la plataforma intercambia el token de actualización almacenado a fin de obtener un token de acceso nuevo y válido que sea necesario para llamar a las API de Google.