Describe the problem/error/question
I’m setting up a workflow using a GCP Service Account with Domain Wide Delegation in Google Workspace (yes, OAuth2 is not an option here).
In general this is working fine, the SA has the scope for Google Drive, the n8n Google Drive node can impersonate any user and access the files in Google Drive. So far so good, my setup is correct.
But when I try to set up the credentials in /home/credentials and add a fixed account in impersonation, I get this error when saving:
Couldn’t connect with these settingsPrivate key validation failed: 401 - {“error”:“unauthorized_client”,“error_description”:“Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested.”}
I can ignore this error, still save the credentials, and as mentioned above, later in the Google Drive node everything is working fine. It can actually impersonate the given user in the scope for Google Drive.
My assumption is, that for validating my input, a test token is created with an arbitrary scope that seems to be not Google Drive.
I already tested adding openid and some other generic scopes like userinfo.email to my service account, but none did help. I don’t want to test the very long list of possible Google Scopes. So my question is: which scope is actually used to validate the input when creating a Google Service Account Credential that is impersonating a user?
Information on your n8n setup
- n8n version: 2.11.2, self-hosted
Yeah, your theory is probably right: the save-time credential validation is likely requesting a token with a generic Google API scope that is different from the Drive scope you delegated, which is why the credential test fails even though the Google Drive node itself works later.\n\nIn practice, that usually means the node-specific operation is using the correct Drive scope at runtime, but the credential validator is doing a separate check that is not perfectly aligned with the actual node usage. That would also explain why adding openid / userinfo.email did not help.\n\nA few things I would test:\n1. Check the exact scopes granted in Google Workspace Admin for domain-wide delegation and make sure the Drive scope used by n8n is explicitly included.\n2. Try the credential without fixed impersonation and only set the impersonated user at node/runtime level, if your workflow allows it.\n3. Inspect n8n server logs while saving the credential to see whether the failing token request exposes the scope being requested. That is usually the fastest way to stop guessing.\n4. If you can reproduce this consistently on 2.11.2, it may be worth opening it as a bug/UX issue, because a validator that fails while the actual node works is pretty misleading.\n\nSo short version: I would not assume there is a single magical extra scope you are missing yet. This smells more like a mismatch between credential validation scope(s) and runtime scope(s) in n8n.
Hi @Jerome_Waibel , welcome to the n8n community 
I don’t think your Drive impersonation setup is the real problem, since the Google Drive node works after the credential is saved. This looks more like a save-time validation quirk in n8n than an actual scope issue in your workflow. As a workaround, I’d save the credential despite the validation error and verify it directly in the Google Drive node, since that is the real API path you care about.
If you want to be extra safe, keep only the exact Google Drive scope enabled in Domain-Wide Delegation and avoid adding unrelated scopes unless you confirm they are needed.