[null,null,["最后更新时间 (UTC)：2025-08-29。"],[[["\u003cp\u003eApplications must utilize OAuth 2.0 for authorization to access the Tag Manager API and user data.\u003c/p\u003e\n"],["\u003cp\u003eAuthorization involves registering your application, requesting specific scopes of access, and obtaining an access token upon user consent.\u003c/p\u003e\n"],["\u003cp\u003eDifferent OAuth 2.0 flows cater to various application types, including web server, client-side, installed apps, and service accounts.\u003c/p\u003e\n"],["\u003cp\u003eCommon issues like expired tokens or insufficient user permissions result in 401 or 403 status codes.\u003c/p\u003e\n"],["\u003cp\u003eThe OAuth 2.0 Playground helps troubleshoot authorization issues by allowing you to inspect the entire authorization process.\u003c/p\u003e\n"]]],["Applications must use OAuth 2.0 to authorize requests to the Tag Manager API. This process involves registering the application with Google, activating the API, and requesting specific scopes of access. Users then consent to grant access, and Google provides an access token. Applications use this token to request data. Various OAuth 2.0 flows cater to web server, client-side, installed apps, and service account use cases, each with specific authentication steps. Refresh tokens allow persistent access. Errors like 401 or 403 indicate issues with token expiration, scope or user access rights.\n"],null,["# Tag Manager API Authorization\n\nThe document describes how an application can gain authorization to make\nrequests to the Tag Manager API.\n\nAuthorizing Requests\n--------------------\n\nBefore users can view their account information on any Google site,\nthey must first log in with a Google Account. In the same way, when users\nfirst access your application, they need to authorize your application to\naccess their data.\n\nEvery request your application sends to the Tag Manager API must include an authorization token. The token also identifies your application to Google.\n\n### About authorization protocols\n\nYour application must use [OAuth 2.0](https://developers.google.com/identity/protocols/OAuth2) to authorize requests. No other authorization protocols are supported. If your application uses [Sign In With Google](https://developers.google.com/identity/gsi/web), some aspects of authorization are handled for you.\n\n### Authorizing requests with OAuth 2.0\n\nAll requests to the Tag Manager API must be authorized by an authenticated user.\n\nThe details of the authorization process, or \"flow,\" for OAuth 2.0 vary somewhat depending on what kind of application you're writing. The following general process applies to all application types:\n\n1. When you create your application, you register it using the [Google API Console](https://console.cloud.google.com/). Google then provides information you'll need later, such as a client ID and a client secret.\n2. Activate the Tag Manager API in the Google API Console. (If the API isn't listed in the API Console, then skip this step.)\n3. When your application needs access to user data, it asks Google for a particular **scope** of access.\n4. Google displays a **consent screen** to the user, asking them to authorize your application to request some of their data.\n5. If the user approves, then Google gives your application a short-lived **access token**.\n6. Your application requests user data, attaching the access token to the request.\n7. If Google determines that your request and the token are valid, it returns the requested data.\n\nSome flows include additional steps, such as using **refresh tokens** to acquire new access tokens. For detailed information about flows for various types of applications, see Google's [OAuth 2.0 documentation](https://developers.google.com/identity/protocols/OAuth2).\n\nHere's the OAuth 2.0 scope information for the Tag Manager API:\n\n| Scope | Meaning |\n|---------------------------------------------------------------------|----------------------------------------------------------|\n| `https://www.googleapis.com/auth/tagmanager.readonly` | View your Google Tag Manager containers. |\n| `https://www.googleapis.com/auth/tagmanager.edit.containers` | Manage your Google Tag Manager containers. |\n| `https://www.googleapis.com/auth/tagmanager.delete.containers` | Delete your Google Tag Manager containers. |\n| `https://www.googleapis.com/auth/tagmanager.edit.containerversions` | Manage your Google Tag Manager container versions. |\n| `https://www.googleapis.com/auth/tagmanager.publish` | Publish your Google Tag Manager containers. |\n| `https://www.googleapis.com/auth/tagmanager.manage.users` | Manage user permissions of your Google Tag Manager data. |\n| `https://www.googleapis.com/auth/tagmanager.manage.accounts` | Manage your Google Tag Manager accounts. |\n\nTo request access using OAuth 2.0, your application needs the scope information, as well as\ninformation that Google supplies when you register your application (such as the client ID and the\nclient secret).\n\nGetting Started\n---------------\n\nTo get started using Tag Manager API, you need to first\n[use\nthe setup tool](https://console.cloud.google.com/start/api?id=tagmanager&credential=client_key), which guides you through creating a project in the\nGoogle API Console, enabling the API, and creating credentials.\n\nTo set up a new service account, do the following:\n\n1. Click **Create credentials \\\u003e Service account key**.\n2. Choose whether to download the service account's public/private key as a standard P12 file, or as a JSON file that can be loaded by a Google API client library.\n\nYour new public/private key pair is generated and downloaded to your machine;\nit serves as the only copy of this key. You are responsible for storing it\nsecurely.\n\nCommon OAuth 2.0 Flows\n----------------------\n\nThe following guidelines outline common use cases for specific OAuth 2.0\nflows:\n\n### [Web Server](/accounts/docs/OAuth2WebServer)\n\nThis flow is good for automated/offline/scheduled access of a user's Google\nTag Manager account. \nExample:\n\n- Automatically updating Tag Manager information from a server.\n| **Note** : The user has to complete a one-time auth flow to grant your application offline access to their Google Tag Manager data. Afterwards, a [refresh token](/accounts/docs/OAuth2WebServer#offline) can be used to obtain a new access token.\n\n### [Client-side](/accounts/docs/OAuth2UserAgent)\n\nIdeal for when users interact directly with the application to\naccess their Google Tag Manager Account within a browser.\nThis flow eliminates the need for server-side capabilities, but it also\nmakes it impractical for automated/offline/scheduled reporting. \nExample:\n\n- A customized browser based configuration tool.\n\n### [Installed Apps](/accounts/docs/OAuth2InstalledApp)\n\nFor applications that are distributed as a package and installed by the user.\nIt requires that the application or user have access to a browser to\ncomplete the authentication flow. \nExamples:\n\n- A desktop widget on a PC or Mac.\n- A plugin for a content management system. The benefit of this flow compared to web server or client-side is that a single API Console project can be used for your application. This allows for a simpler installation for users.\n\n### [Service Accounts](/accounts/docs/OAuth2ServiceAccount)\n\nUseful for automated/offline/scheduled access your own Google Tag Manager\naccount. For example, to build a custom tool to monitor your own\nGoogle Tag Manager account and share it with other users.\n\nTroubleshooting\n---------------\n\nIf your `access_token` has expired or you use the wrong scope\nfor a particular API call you get a `401` status code in the\nresponse.\n\nIf the authorized user does not have access to the Google Tag Manager account\nor container you get a `403` status code in the response. Make sure\nyou are authorized with the correct user and that you have been granted\n[permissions](/tag-platform/tag-manager/api/v2/reference/accounts/user_permissions)\nto access the Tag Manager account or container.\n\n### OAuth 2.0 Playground\n\nThe\n[OAuth 2.0 Playground](//developers.google.com/oauthplayground/)\nallows you to go through the entire authorization\nflow through a web interface. The tool also displays all the HTTP request\nheaders required for making an authorized query. If you can't get\nauthorization to work in your own application, you should try to get it\nworking through the OAuth 2.0 Playground. Then you can compare the HTTP\nheaders and request from the playground to what your application is sending.\nThis check is a simple way to ensure you are formatting your requests\nproperly.\n\n### Invalid grant\n\nIf you receive an `invalid_grant` error response when attempting\nto use a refresh token, the error might be caused by one or both of the\nfollowing things:\n\n1. Your server's clock is not in sync with [NTP](http://en.wikipedia.org/wiki/Network_Time_Protocol).\n2. You have exceeded the refresh token limit. \n Applications can request multiple refresh tokens to access a single Google Tag Manager account. For example, this is useful in situations where a user wants to install an application on multiple machines and access the same Google Tag Manager account. In this case, two refresh tokens are required, one for each installation. When the number of refresh tokens exceeds the limit, older tokens become invalid. If the application attempts to use an invalidated refresh token, an `invalid_grant` error response is returned. Each unique client-ID/account combination can have up to 25 refresh tokens. (Note that this limit is subject to change.) If the application continues to request refresh tokens for the same Client-ID/account combination, once the 26th token is issued, the 1st refresh token that was issued becomes invalid. The 27th requested refresh token invalidates the 2nd issued token, and so on."]]
