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?

Abohm

Google Cloud Platform and Google Workspace are two different services. To grant a service account the ability to access data in Workspace requires impersonating a user in Workspace that has privileges to access the data or make the API call. Imagine that you work for Company A. Company A sends you to company B who then gives you a new badge for work inside Company B. When you are at Company B you are impersonating as a Company B employee and are temporarily managed by Company B's personnel department. – Achromatin

I see the big difference between GCP and Workspace now, which is a bit of a surprise as I thought it would be a bit more joined together. The thing that confuses me is that it seems more like when given a badge for working in "Company B", it feels more like I'm given a duplicate of someone's badge, which seems wrong. I would prefer it if the Service Account's work was done in it's own name, and so it's easy to differentiate what is the impersonated user and what is the Service Account. I'm sure impersonation is good for certain situations, but I'm struggling to find when that would be – Abohm

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.

Fico

Just to confirm, the main thing that having a Service Account achieves is to avoid using the OAuth2 flow? I've done some more research and trying to work out if OAuth2 with access_type=offline is better as I could just continue to use the same token and not have to worry about service accounts – Abohm

Yes, pretty much using a service account and performing impersonation allows you to make changes through API calls without the user providing consent through a consent screen, the regular Oauth2 flow as you mentioned. – Fico

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.

Notochord

This is a massive help, thanks Johannes. I've been able to remove the impersonation and Domain-wide Delegation and still have the calls work. I made a specific role for my service account so I can give it the correct permissions. The role permissions are not as specific as the API Roles though, so I've had to give it some write access which I'd rather not do. I assume there's no way to do this but at an API Scope level? – Abohm

If a privilege grants more access then you a actually need, consider using scopes to narrow down access, for example to read-only. – Notochord

According to that documentation, scopes are only available in OAuth2. This is fine, and potentially the route I'm going to go down. I can also use scopes successfully when using Domain-wide delegation but then we're back to the impersonation question I began with. I like the fact that you can use roles against service accounts as you initially posted, but without that being able to go down to scope level it's probably not going to work for my use case – Abohm

This answer helps indeed. How would you have done if you wanted to make use of the service account to query other workspaces? Certainly you cannot create custom role or grant group reader/admin role to the workspace, right? – Dinerman