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 | Sí | 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 | Sí | Sí |
| Se emitió un token de actualización | No | Sí |
| Se requiere un navegador compatible | Sí | Sí |
| 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. |