En el documento, se describe cómo una aplicación puede obtener autorización para realizar solicitudes a la API de Tag Manager.
Autoriza solicitudes
Antes de que los usuarios puedan ver la información de su cuenta en cualquier sitio de Google, primero deben acceder con una Cuenta de Google. De la misma manera, cuando los usuarios acceden a tu aplicación por primera vez, deben autorizarla para acceder a sus datos.
Cada solicitud que tu aplicación envía a la API de Tag Manager debe incluir un token de autorización. El token también identifica tu aplicación ante Google.
Acerca de los protocolos de autorización
Tu aplicación debe usar OAuth 2.0 para autorizar solicitudes. No se admiten otros protocolos de autorización. Si tu aplicación usa Acceder con Google, tú controlarás algunos aspectos de la autorización.
Solicitudes de autorización con OAuth 2.0
Todas las solicitudes a la API de Tag Manager deben contar con la autorización de un usuario autenticado.
Los detalles del proceso de autorización, o "flujo", para OAuth 2.0 varían de alguna manera según el tipo de aplicación que estás escribiendo. El siguiente proceso general se aplica a todos los tipos de aplicación:
- Cuando crees tu aplicación, deberás registrarla con Google API Console. Luego, Google proporcionará la información que necesites más tarde, como el ID y un secreto del cliente.
- Activa la API de Tag Manager en la Consola de API de Google. Si no aparece en la consola de API, omite este paso.
- Cuando la aplicación necesite acceder a datos del usuario, solicita a Google un alcance de acceso en particular.
- Google mostrará una pantalla de consentimiento al usuario, en la que le pedirá que permita a la aplicación solicitar algunos de sus datos.
- Si el usuario la aprueba, Google le otorgará a la aplicación un token de acceso de corta duración.
- La aplicación solicitará los datos del usuario y adjuntará el token de acceso a la solicitud.
- Si Google determina que la solicitud y el token son válidos, mostrará los datos solicitados.
Algunos flujos requieren pasos adicionales, como el uso de tokens de actualización, para adquirir nuevos tokens de acceso. Si deseas obtener información detallada sobre los flujos para varios tipos de aplicaciones, consulta la documentación de OAuth 2.0 de Google.
A continuación, se incluye información del alcance de OAuth 2.0 para la API de Tag Manager:
| Permiso | Significado |
|---|---|
https://www.googleapis.com/auth/tagmanager.readonly |
Visualiza tus contenedores del Administrador de etiquetas de Google. |
https://www.googleapis.com/auth/tagmanager.edit.containers |
Administra tus contenedores del Administrador de etiquetas de Google. |
https://www.googleapis.com/auth/tagmanager.delete.containers |
Borra los contenedores del Administrador de etiquetas de Google. |
https://www.googleapis.com/auth/tagmanager.edit.containerversions |
Administra las versiones de tu contenedor del Administrador de etiquetas de Google. |
https://www.googleapis.com/auth/tagmanager.publish |
Publica tus contenedores del Administrador de etiquetas de Google. |
https://www.googleapis.com/auth/tagmanager.manage.users |
Administra los permisos de usuario de tus datos del Administrador de etiquetas de Google. |
https://www.googleapis.com/auth/tagmanager.manage.accounts |
Administra tus cuentas del Administrador de etiquetas de Google. |
Para solicitar acceso con OAuth 2.0, tu aplicación necesita los datos del alcance, además de la información que Google proporciona cuando registras la aplicación (como el ID y el secreto del cliente).
Getting Started
Para comenzar a usar la API de Tag Manager, primero debes utilizar la herramienta de configuración, que te guiará para crear un proyecto en la Consola de API de Google, habilitar la API y crear credenciales.
Para configurar una cuenta de servicio nueva, sigue estos pasos:
- Haz clic en Crear credenciales > Clave de cuenta de servicio.
- Elige si deseas descargar la clave pública/privada de la cuenta de servicio como un archivo P12 estándar o como un archivo JSON que se puede cargar con una biblioteca cliente de la API de Google.
Ya se generó y descargó el nuevo par de claves pública y privada en tu equipo, que será la única copia. Eres responsable de almacenarlo de forma segura.
Flujos comunes de OAuth 2.0
En los siguientes lineamientos, se describen casos de uso comunes para flujos específicos de OAuth 2.0:
Servidor web
Este flujo es adecuado para el acceso automático, sin conexión o programado de la cuenta de Google Tag Manager de un usuario.
- Actualización automática de la información de Tag Manager desde un servidor
Del lado del cliente
Es ideal cuando los usuarios interactúan directamente con la aplicación para acceder a su cuenta de Google Tag Manager desde un navegador. Este flujo elimina la necesidad de capacidades del servidor, pero también hace que sea poco práctico para la generación de informes automatizados, sin conexión o programados.
- Una herramienta de configuración personalizada basada en el navegador.
Apps instaladas
Para aplicaciones que se distribuyen como un paquete y las instala el usuario Requiere que la aplicación o el usuario tengan acceso a un navegador para completar el flujo de autenticación.
- Un widget de escritorio en una PC o Mac.
- Es un complemento para un sistema de administración de contenido. El beneficio de este flujo en comparación con el servidor web o del cliente es que se puede usar un solo proyecto de la Consola de API para tu aplicación. De esta manera, se permite una instalación más simple para los usuarios.
Cuentas de servicio
Es útil para el acceso automático, sin conexión o programado a tu propia cuenta de Google Tag Manager. Por ejemplo, para crear una herramienta personalizada a fin de supervisar tu propia cuenta de Google Tag Manager y compartirla con otros usuarios.
Solución de problemas
Si tu access_token venció o usas el alcance incorrecto para una llamada a la API en particular, obtendrás un código de estado 401 en la respuesta.
Si el usuario autorizado no tiene acceso a la cuenta o al contenedor de Google Tag Manager,
obtendrás un código de estado 403 en la respuesta. Asegúrate
de estar autorizado con el usuario correcto y de que se te hayan otorgado
permisos
para acceder a la cuenta o al contenedor de Tag Manager.
OAuth 2.0 Playground
OAuth 2.0 Playground te permite pasar por todo el flujo de autorización a través de una interfaz web. La herramienta también muestra todos los encabezados de solicitud HTTP necesarios para realizar una consulta autorizada. Si no puedes obtener autorización para trabajar en tu propia aplicación, debes intentar hacer que funcione a través de OAuth 2.0 Playground. Luego, puedes comparar los encabezados y las solicitudes HTTP de la zona de pruebas con lo que envía tu aplicación. Esta verificación es una manera sencilla de asegurarte de que tus solicitudes se formatean de forma correcta.
Otorgamiento no válido
Si recibes una respuesta de error invalid_grant cuando intentas usar un token de actualización, es posible que el error se deba a uno de los siguientes motivos o ambos:
- El reloj de tu servidor no está sincronizado con NTP.
- Superaste el límite de tokens de actualización.
Las aplicaciones pueden solicitar varios tokens de actualización para acceder a una sola cuenta de Google Tag Manager. Por ejemplo, esto es útil en situaciones en las que un usuario desea instalar una aplicación en varias máquinas y acceder a la misma cuenta de Google Tag Manager. En este caso, se requieren dos tokens de actualización, uno para cada instalación. Cuando la cantidad de tokens de actualización supera el límite, los tokens más antiguos dejan de ser válidos. Si la aplicación intenta usar un token de actualización no válido, se muestra una respuesta de errorinvalid_grant. Cada combinación única de ID de cliente y cuenta puede tener hasta 25 tokens de actualización. (Ten en cuenta que este límite está sujeto a cambios). Si la aplicación continúa solicitando tokens de actualización para la misma combinación de ID de cliente y cuenta, una vez que se emite el token número 26, el primer token de actualización que se emitió deja de ser válido. El token de actualización número 27 solicitado invalida el segundo token emitido, y así sucesivamente.