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 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.
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.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2023-12-01 (UTC)"],[[["\u003cp\u003eThis guide helps developers choose between Google Identity Services or a custom JavaScript library for OAuth 2.0 authorization in their web applications.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Identity Services offers pre-built security features, optimized user experience, and easier implementation compared to building a custom solution.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers need to select between the Implicit or Authorization Code flow based on security, user presence requirements, and backend needs.\u003c/p\u003e\n"],["\u003cp\u003eAuthorization Code flow is recommended for enhanced security, offline access, and refresh token management through a backend server.\u003c/p\u003e\n"],["\u003cp\u003eThe guide assumes prior knowledge of OAuth 2.0 concepts and focuses solely on authorization and data sharing, not user authentication.\u003c/p\u003e\n"]]],[],null,["# Choose a user authorization model\n\nThis guide helps you to choose between using the Google Identity Services\nlibrary for user authorization or implementing your own JavaScript library. It\nhelps you decide which OAuth 2.0 authorization flow is best for your web\napplication.\n\nPrior to reading this guide it is assumed that you are familiar with the terms\nand concepts described in the [Overview](/identity/oauth2/web/guides/overview) and\n[How user authorization works](/identity/oauth2/web/guides/how-user-authz-works) guide.\n\nThe GIS library runs in these [supported browsers](/identity/gsi/web/guides/supported-browsers) on the user's device. It\nis not intended for use with server-side JavaScript frameworks such as Node.js,\ninstead use Google's [Node.js](https://github.com/googleapis/google-api-nodejs-client)\nclient library.\n\nThis guide only covers authorization and data sharing topics. It does not review\nuser authentication, instead see [Sign In With Google](/identity/gsi/web) and the [Migrating\nfrom Google Sign-In](/identity/gsi/web/guides/migration) guide for user sign-up and sign-in.\n\nDeciding if the GIS library is right for you\n--------------------------------------------\n\nYou must choose if using Google's library, or creating your own best fits your\nneeds. An overview of features and functionality:\n\n- Google's Identity Services JavaScript library implements:\n - Popup based consent flows to minimize redirects, thus enabling users to remain on your site throughout the authorization process.\n - Security features such as Cross-site Request Forgery (CRSF).\n - Helper methods to request individual scopes and confirm user consent.\n - Human friendly error handling and documentation links for use by engineers during development and later for visitors to your site.\n- When implementing without the Identity Services library you are responsible for:\n - Managing requests and responses with Google's OAuth 2.0 endpoints, including redirects.\n - Optimizing the user experience.\n - Implementation of security features to validate requests, responses, and to prevent CSRF.\n - Methods to confirm a user has granted consent for any requested scopes.\n - Managing OAuth 2.0 error codes, creating human readable messages, and links to user help.\n\nIn summary, Google offers the GIS library to help you to quickly, and securely\nimplement an OAuth 2.0 client and optimize the user's authorization experience.\n\nChoosing an authorization flow\n------------------------------\n\nYou will need to choose one of two OAuth 2.0 authorization flows: implicit or\nauthorization code -- regardless if you decide to use the Google Identity\nServices JavaScript library or to create your own library.\n\nBoth flows result in an access token which can be used to call Google APIs.\n\nThe primary differences between the two flows are:\n\n- the number of user actions,\n- whether your app will call Google APIs without the user present,\n- if a backend platform is needed to host an endpoint and to store per-user refresh tokens for individual user accounts, and\n- higher or lower levels of user security.\n\nWhen comparing flows and evaluating your security requirements, a factor to\nconsider is that the level of user security varies depending on the scopes you\nchoose. For example, viewing calendar invites as read-only might be considered\nless risky than using a read/write scope to edit files in Drive.\n| **Key Point:** Authorization code flow is recommended because it provides a more secure flow.\n\nOAuth 2.0 flow comparison\n-------------------------\n\n|--------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|\n| | **Implicit flow** | **Authorization code flow** |\n| **User consent required** | For every token request, including replacing expired tokens. | Only for the first token request. |\n| **User must be present** | Yes | No, supports offline use. |\n| **User security** | Least | Most, has client authentication and avoids in-browser token handling risks. |\n| **Access token issued** | Yes | Yes |\n| **Refresh token issued** | No | Yes |\n| **Supported browser required** | Yes | Yes |\n| **Access token used to call Google APIs** | only from a web app running in the user's browser. | either from a server running on backend platform, or from a web app running in the user's browser. |\n| **Requires backend platform** | No | Yes, for endpoint hosting and storage. |\n| **Secure storage needed** | No | Yes, for refresh token storage. |\n| **Requires hosting of an authorization code endpoint** | No | Yes, to receive authorization codes from Google. |\n| **Access token expiration behavior** | A user gesture such as button press or clicking on a link is required to request and obtain a new, valid access token. | After an initial user request, your platform exchanges the stored refresh token to obtain a new, valid access token necessary to call Google APIs. |"]]
