Esta guía te ayuda 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 descritos en las guías Descripción general y Cómo funciona la autorización de usuarios.
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. En su lugar, usa la biblioteca cliente Node.js de Google.
En esta guía, solo se abarcan temas de autorización y uso compartido de datos. No se revisa la autenticación del usuario. En su lugar, consulta Acceder con Google y la guía Cómo migrar desde el Acceso con Google para el registro y 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 si crear una propia que se adapte mejor a tus necesidades. Descripción general de las características y funciones:
- La biblioteca JavaScript de Identity Services 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.
- Manejo de errores fácil de usar y vínculos de documentación para que los ingenieros los usen durante el desarrollo y, luego, los visitantes de tu sitio
- Si implementas sin la biblioteca de Identity Services, 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 evitar CSRF.
- Métodos para confirmar que un usuario otorgó su consentimiento para cualquier permiso solicitado
- Administrar los códigos de error de OAuth 2.0, crear mensajes legibles por humanos y vínculos a la ayuda del usuario
En resumen, Google ofrece la biblioteca de GIS para ayudarte a implementar con rapidez y seguridad 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: código implícito o de autorización, independientemente de si decides usar la biblioteca 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 aplicación 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úas tus requisitos de seguridad, un factor que debes tener en cuenta es que el nivel de seguridad del usuario varía según los alcances que elijas. Por ejemplo, ver las invitaciones del calendario como de solo lectura puede considerarse menos riesgoso que usar un permiso de lectura/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 aplicación web que se ejecuta en el navegador del usuario. | ya sea desde un servidor que se ejecute en una plataforma de backend o desde una app web que se ejecute en el navegador del usuario. |
| Requiere la 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 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 nuevo token de acceso válido. | Después de una solicitud inicial de usuario, la plataforma intercambia el token de actualización almacenado para obtener un token de acceso válido nuevo que es necesario para llamar a las APIs de Google. |