En esta guía, se te ayudará a elegir entre usar la biblioteca de Google Identity Services 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 mejor para tu aplicación web.
Antes de leer esta guía, se supone que conoces los términos y conceptos que se describen en la guía de Descripción general y Cómo funciona la autorización del usuario.
La biblioteca de GIS se ejecuta en estos navegadores compatibles en el dispositivo del usuario. No está diseñada para usarse con frameworks de JavaScript del servidor, como Node.js. En su lugar, usa la biblioteca cliente de Node.js de Google.
En esta guía, solo se abordan temas relacionados con la autorización y el uso compartido de datos. No revisa la autenticación del usuario. En su lugar, consulta Acceder con Google y la guía Migración desde Acceder con Google para el registro y el acceso de usuarios.
Cómo decidir si la biblioteca de GIS es adecuada para ti
Debes elegir si usar la biblioteca de Google o crear la tuya propia se adapta mejor a tus necesidades. Descripción general de las funciones y la funcionalidad:
- La biblioteca de JavaScript de Google Identity Services implementa lo siguiente:
- Flujos de consentimiento basados en diálogos 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).
- Son métodos auxiliares para solicitar permisos individuales y confirmar el consentimiento del usuario.
- Manejo de errores y vínculos a la documentación fáciles de usar para los ingenieros durante el desarrollo y, luego, para los visitantes de tu sitio.
- Cuando implementas sin la biblioteca de Identity Services, eres 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 evitar ataques CSRF
- Son métodos para confirmar que un usuario otorgó su consentimiento para los alcances solicitados.
- Administrar códigos de error de OAuth 2.0, crear mensajes legibles y vínculos a la ayuda para el 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.
Cómo elegir un flujo de autorización
Deberás elegir uno de los dos flujos de autorización de OAuth 2.0: implícito o código de autorización, independientemente de si decides usar la biblioteca de JavaScript de Google Identity Services o crear tu propia biblioteca.
Ambos flujos generan un token de acceso que se puede usar para llamar a las APIs de Google.
Las principales diferencias entre los dos flujos son las siguientes:
- la cantidad de acciones del usuario
- Si tu app llamará a las APIs 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 de seguridad del usuario más altos o más bajos.
Cuando compares flujos y evalúes tus requisitos de seguridad, ten en cuenta que el nivel de seguridad del usuario varía según los permisos que elijas. Por ejemplo, ver las invitaciones del calendario como de solo lectura podría considerarse 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 cliente 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 APIs de Google | solo desde una app web que se ejecuta en el navegador del usuario. | ya sea desde un servidor que se ejecuta en la plataforma de backend o desde una app web que se ejecuta en el navegador del usuario. |
| Requiere una plataforma de backend | No | Sí, para el alojamiento y el almacenamiento de endpoints. |
| Se necesita almacenamiento seguro | No | Sí, para el almacenamiento de tokens de actualización. |
| Requiere el alojamiento de un extremo de código de autorización | No | Sí, para recibir códigos de autorización de Google |
| Comportamiento del vencimiento del token 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 token de acceso nuevo y válido. | Después de una solicitud inicial del usuario, tu plataforma intercambia el token de actualización almacenado para obtener un token de acceso nuevo y válido necesario para llamar a las APIs de Google. |