Autorización de la API de Tag Manager

En este documento se describe cómo puede una aplicación obtener autorización para realizar solicitudes a la API de Tag Manager.

Autorizar solicitudes

Para que los usuarios puedan ver la información de sus cuentas en cualquier sitio web de Google, primero deben iniciar sesión con una cuenta de Google. Del mismo modo, cuando acceden por primera vez a tu aplicación, deben concederle autorización para que acceda a sus datos.

Cada solicitud que envía tu aplicación a la API de Tag Manager debe incluir un token de autorización. Este token también identifica tu aplicación en Google.

Acerca de los protocolos de autorización

Tu aplicación debe utilizar OAuth 2.0 para autorizar las solicitudes. No se admite ningún otro protocolo de autorización. Si tu aplicación usa el inicio de sesión de Google, algunos aspectos de la autorización se gestionan automáticamente.

Autorizar solicitudes con OAuth 2.0

Todas las solicitudes a la API de Tag Manager deben estar autorizadas por un usuario autenticado.

Los detalles del proceso de autorización, o "flujo", de OAuth 2.0 varían ligeramente dependiendo del tipo de aplicación que crees. El siguiente proceso general se aplica a todos los tipos de aplicación:

  1. Cuando crees tu aplicación, debes registrarla con la consola de APIs de Google. A continuación, Google proporciona la información que necesitarás posteriormente, como un ID de cliente y un secreto de cliente.
  2. Activa la API de Tag Manager en la consola de APIs de Google. Si la API no aparece en la consola de APIs, sáltate este paso.
  3. Cuando tu aplicación necesite acceder a los datos del usuario, esta solicitará a Google un determinado alcance de acceso.
  4. Google muestra una pantalla de consentimiento al usuario pidiéndole su autorización para que la aplicación solicite algunos de sus datos.
  5. Si el usuario lo autoriza, Google proporcionará a la aplicación un token de acceso de corta duración.
  6. Tu aplicación solicita los datos del usuario y adjunta el token de acceso a la solicitud.
  7. Si Google determina que tu solicitud y el token son válidos, muestra los datos solicitados.

En algunos flujos se incluyen pasos adicionales, como el uso de tokens de actualización para adquirir nuevos tokens de acceso. Para obtener más información acerca de los flujos de los distintos tipos de aplicaciones, consulta la documentación de OAuth 2.0 de Google.

A continuación, te indicamos la información de alcance de OAuth 2.0 para la API de Tag Manager:

Alcance Significado
https://www.googleapis.com/auth/tagmanager.readonly Consulta tus recursos Container de Google Tag Manager.
https://www.googleapis.com/auth/tagmanager.edit.containers Gestiona tus recursos Container de Google Tag Manager.
https://www.googleapis.com/auth/tagmanager.delete.containers Elimina tus recursos Container de Google Tag Manager.
https://www.googleapis.com/auth/tagmanager.edit.containerversions Gestiona tus recursos Container Versions de Google Tag Manager.
https://www.googleapis.com/auth/tagmanager.publish Publica tus recursos Container de Google Tag Manager.
https://www.googleapis.com/auth/tagmanager.manage.users Gestiona tus recursos User Permissions de tus datos de Google Tag Manager.
https://www.googleapis.com/auth/tagmanager.manage.accounts Gestiona tus recursos Accounts de Google Tag Manager.

Para solicitar acceso mediante OAuth 2.0, tu aplicación necesita la información del alcance, así como la información que proporciona Google cuando se registra la aplicación (como el ID y el secreto de cliente).

Empezar

Para empezar a usar la API de Tag Manager, primero debes utilizar la herramienta de configuración, que te guiará por los pasos necesarios para crear un proyecto en la consola de APIs de Google, habilitar la API y crear las credenciales.

Para crear una cuenta de servicio, sigue estos pasos:

  1. Haz clic en Crear credenciales > Clave de cuenta de servicio.
  2. Decide si quieres descargar el par de claves pública/privada de la cuenta de servicio como un archivo P12 estándar o como un archivo JSON que pueda cargar una biblioteca de cliente de APIs de Google.

Se genera el par de claves pública/privada y se descarga en el equipo, lo que sirve de copia única de esta clave. Eres responsable de almacenarlo de forma segura.

Flujos de OAuth 2.0 habituales

En las directrices siguientes se describen los casos prácticos habituales de determinados flujos de OAuth 2.0:

Servidor web

Este flujo resulta adecuado para el acceso automático, sin conexión o programado de la cuenta de Google Tag Manager de un usuario.

Ejemplo:
  • Actualizar de forma automática la información de Tag Manager desde un servidor.

Cliente

Es ideal cuando los usuarios interactúan directamente con la aplicación para acceder a sus respectivas cuentas de Google Tag Manager desde un navegador. Con este flujo no se necesitan funciones en el servidor, pero no se pueden crear informes automáticos, sin conexión o programados.

Ejemplo:
  • Una herramienta de configuración personalizada basada en navegador.

Aplicaciones descargadas

Para aplicaciones que se distribuyen en paquetes e instala el usuario. Es necesario que la aplicación o el usuario tengan acceso a un navegador para completar el flujo de autenticación.

Ejemplos:
  • Un widget de ordenador en un PC o Mac.
  • Un complemento de un sistema de gestión de contenido. La ventaja de este flujo, en relación con el de servidor web o de cliente, es que se puede usar un solo proyecto de la consola de APIs para la aplicación. Esto simplifica la instalación a los usuarios.

Cuentas de servicio

Resulta útil para el acceso automático, sin conexión o programado a tu cuenta de Google Tag Manager. Por ejemplo, para crear una herramienta personalizada que supervise tu cuenta de Google Tag Manager y compartirla con otros usuarios.

Solucionar problemas

Si tu token de acceso (access_token) ha caducado o si utilizas un alcance incorrecto para una determinada llamada a la API, se muestra 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, se muestra un código de estado 403 en la respuesta. Debes estar autorizado con el usuario adecuado y haber obtenido permisos para acceder a la cuenta o al contenedor de Tag Manager.

OAuth 2.0 Playground

OAuth 2.0 Playground te permite llevar a cabo todo el proceso de autorización mediante una interfaz web. En la herramienta también se muestran todos los encabezados de solicitud HTTP necesarios para realizar una solicitud autorizada. Si no consigues que la autorización funcione en tu aplicación, debes probar a que lo haga mediante OAuth 2.0 Playground. Después, puedes comparar los encabezados HTTP y solicitar a Playground qué envía tu aplicación. Esta comprobación es una forma sencilla de asegurarte de que aplicas el formato correcto a tus solicitudes.

Concesión no válida

Si recibes una respuesta de error invalid_grant al intentar utilizar un token de actualización, puede que la causa de dicho error sea una de las que se indican a continuación (o ambas):

  1. El reloj de tu servidor no está sincronizado con NTP.
  2. Has superado 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. Resulta útil, por ejemplo, si un usuario quiere instalar una aplicación en varios equipos 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 el número de tokens de actualización supera el límite, los tokens anteriores dejan de ser válidos. Si la aplicación intenta utilizar un token de actualización invalidado, se devuelve la respuesta de error invalid_grant. Cada combinación de Client-ID y cuenta puede tener hasta 25 tokens de actualización. Este límite está sujeto a cambios. Si la aplicación sigue solicitando tokens de actualización para la misma combinación de Client-ID y cuenta, cuando se solicita 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 que se solicite invalidará el segundo token emitido, y así sucesivamente.