Esta guía te ayuda a elegir entre usar la biblioteca de Google Identity Services para autorizar al 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 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 que usa la biblioteca cliente de Node.js de Google.
En esta guía, solo se tratan los temas de autorización y uso compartido de datos. No revisa la autenticación del usuario, en su lugar, consulta Accede con Google y la guía Migra desde el Acceso con Google para el registro y el acceso de los usuarios.
Decide si la biblioteca de GIS es adecuada para ti
Debes elegir si deseas usar la biblioteca de Google o crear una propia que se adapte mejor a tus necesidades. Descripción general de las características y funciones:
- La biblioteca JavaScript de los Servicios de identidad de Google implementa:
- Flujos de consentimiento basados en ventanas emergentes para minimizar los redireccionamientos, lo que permite a los usuarios permanecer 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 manejo y documentación de errores fáciles de usar para que los ingenieros los usen durante el desarrollo y después 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 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 la 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 los dos flujos de autorización de OAuth 2.0: implícito o código de autorización, sin importar 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 diferencias principales entre los dos flujos son las siguientes:
- la cantidad de acciones del usuario,
- si tu app llamará a las APIs de Google sin que el usuario esté presente
- si se necesita una plataforma de backend a fin de 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 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, considerar las invitaciones de calendario como de solo lectura podría considerarse menos riesgoso que usar un permiso de lectura/escritura para editar archivos en Drive.
Comparación de flujos 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, se admite el uso sin conexión. |
| Seguridad del usuario | Menos | La mayoría tiene autenticación de clientes y evita riesgos de manejo de token en el navegador. |
| Token de acceso emitido | Sí | Sí |
| Token de actualización emitido | 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 una plataforma de backend o desde una app web que se ejecuta en el navegador del usuario. |
| Se requiere la plataforma de backend | No | Sí, para el hosting y almacenamiento de extremos. |
| Almacenamiento seguro necesario | No | Sí, para el almacenamiento de tokens de actualización. |
| Requiere el hosting de un extremo del 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, tu plataforma intercambia el token de actualización almacenado por un token de acceso nuevo y válido necesario para llamar a las API de Google. |