Does a Service Account have to impersonate a user to access the Directory Api?

Question

I think I might be misunderstanding how Service Accounts work in GCP, as I don't understand why (in my situation) they need to impersonate a user to complete a task.

I need to access some information that is within the Workspace Admin SDK API (for example listing chromeos devices ) on my application without prompting a user to log in. I thought the best way to do this was using a service account to do this, so I could upload the details of my service account to my application, and every time I required some data it would do so via this account.

I have created my Service Account in GCP, and then given it Domain-wide Delegation with the required scopes in Google Workspace.

At first when testing this I was getting Forbidden 403 errors because I was not impersonating any user. Once I starting impersonating a user, I was able to get the data I required from the API. I also confirmed that when I removed some of the scopes on the Domain-wide Delegation, I was no longer able to retrieve that data. This means that while I was impersonating a Super Admin, I was only able to get the data for the scopes I had provided the Service Account.

This leads me to the question as to why I need to impersonate anyone in the first place?

Is this just a problem with the Directory API? In their documentation , it states that

Note: Only users with access to the Admin APIs can access the Admin SDK Directory API, therefore your service account needs to impersonate one of those users to access the Admin SDK Directory API. Additionally, the user must have logged in at least once and accepted the Google Workspace Terms of Service.

So my question is: Am I able to make calls to the Directory API as a Service Account without having to impersonate a user? If not, is it possible to make any API calls as a service account without impersonating a user, or is this just a Directory API issue?

Answer 1

Related to this question:

why I need to impersonate anyone in the first place?

The service account allows you to authenticate and be authorized to access data in Google APIs as documented here , by performing domain wide delegation you are granting access the service account to access your account data by impersonating a user from your domain. You can look at a service account as a way to automatize authorization as it can perform changes over several APIs not only the Admin SDK and avoid having the user impersonated to be providing access to a given API each time.

You can make calls to an API without impersonating an user but that would lead to accessing data available to the service account only as it's data belonging to their own, meaning that for example, if you make a Drive API call to create a document using a service account without impersonating it, the file could be created but it will only belong to the service account and you won't be able to access that data as an Administrator the data won't belong to your domain since the service account is different than a user account, you can check more about this in this documentation .

Now related to the last question about impersonating a user, impersonation is a way for you to make API calls on behalf of a user so that user doesn't needs to be providing API access each time that you need to perform changes, this applies to Super Admin users and regular users, this is as well noted in the documentation:

In enterprise applications you may want to programmatically access a user's data without any manual authorization on their part.

Rather than looking service accounts and impersonation as a problem, you could think about it as a way for you to make changes over your users through API without requiring them to give you access to do so. Impersonation allows you to make several changes and can help your organization to automatize several tasks when API calls are needed.

Answer 2

That depends on which resource/method you're using, and which privileges it requires.

For example, you can grant a service account the Groups Reader or Groups Admin admin role, and then that service account can call the methods of the groups resource. No domain-wide delegation required.

But that doesn't work for all resources/methods, and in particular it doesn't work for those that require super-admin privileges. To call these methods, you have to use domain-wide delegation to impersonate a user that has super-admin privileges.