Service account impersonation with --scopes doesn't work as documented

[SebastianMohrStade]

The README's service account impersonation instructions don't work as documented due to a known limitation in Google's authentication libraries.

Problem:

gcloud auth application-default login \
  --impersonate-service-account=SERVICE_ACCOUNT_EMAIL \
  --scopes=https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform

The --scopes parameter is ignored when using impersonation with ADC. The generated token only contains cloud-platform scope, missing analytics.readonly.

Test to reproduce:

After running the README's impersonation command:

TOKEN=$(gcloud auth application-default print-access-token)
curl "https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=$TOKEN"

Output shows only: "scope": "https://www.googleapis.com/auth/cloud-platform"
Missing: https://www.googleapis.com/auth/analytics.readonly
This causes 403 errors when the MCP server attempts Data API calls.

Root cause:
Google confirmed this is a limitation - scopes aren't stored in the ADC file format for impersonated service accounts. See: googleapis/google-auth-library-python#1204

</claude summary>

This was quite annoying to figure out, from the Issue discussion in the python lib, it is 'working as expected' and too much effort to fix. Therefore to spare future users of the MCP server please mention that in the readme.

[jradcliff]

Hi @SebastianMohrStade ,

By default, the gcloud auth application-default print-access-token command only generates an access token for the following scope for impersonation credentials, even if the default credentials were generated with additional scopes:

https://www.googleapis.com/auth/cloud-platform

If you want to print an access token that includes the Google Analytics scope, add the --scopes parameter to that command.

gcloud auth application-default print-access-token \
  --scopes=https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform

You can verify this by running gcloud auth application-default print-access-token twice:

1. without a --scopes arg, and
2. with the --scopes arg

and then append each access token to the end of the following URL:

https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=

The output for access token 1 will be:

{
  "issued_to": "...",
  "audience": "...",
  "scope": "https://www.googleapis.com/auth/cloud-platform",
  "expires_in": 3580
}

The output for access token 2 will be:

{
  "issued_to": "...",
  "audience": "...",
  "scope": "https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/analytics.readonly",
  "expires_in": 3588
}

Could you elaborate on how this affected your ability to set up the MCP server? The MCP server's config just needs a GOOGLE_APPLICATION_CREDENTIALS and GOOGLE_PROJECT_ID, and the server internally handles retrieving access tokens with the required scope. You shouldn't have to generate and explicitly pass an access token to the MCP server.

Thanks,
Josh, Google Analytics team

[SebastianMohrStade]

Thanks @jradcliff for the quick and detailed reply!

I was not aware that the print-access-token requires the scope to be set.

The issue i am facing is this:
I've created a SA with Editor permissions on a GA4 Property. When trying to call any tool using the application_default_credentials.json created by the command from the readme i get this error:
Error executing tool get_account_summaries: 503 Getting metadata from plugin failed with error: 'str' object is not callable

This error seems to be credentials related.
Using the SA key file instead of the application default, I can access everything via the tool calls.

The fact that the scopes need to be set explicitly when printing the token might have put me on the wrong conclusion when debugging this. Nonetheless i can use the SA key file, i cannot use the SA application default json file.
The application default does work via OAuth / my user.

[ggoad]

@SebastianMohrStade for me, I got by this part by making sure python was the correct version. On windows, in the path, my python 2 superseded my python 3