Can applications with Domain-Wide Delegation enabled do more than the scopes allow by impersonating a superadmin?

Question

Applications in GSuite can have domain-wide delegation (DWD) enabled, allowing the application to access user data (and other domain data) without any interaction on the part of the users.

According to a Google Support article, it is implied that the application is limited by the scopes set on the application.

However, reading various responses on Stack Exchange regarding "user impersonation" makes me wonder about the validity of this. See:

• Breno's response "The domain-wide delegation model allows a service account to impersonate a user and thus obtain the same privileges in the domain that the user identity + set of scopes granted to the application imply."
• Kessy's and Gilfoyle's responses "...This means that the service account only has access to data from the account the application is impersonating...." and "...First and foremost: A service account is technically a superadministrator once DWD ..."
• Edited question ("Solution")

There is nothing concrete, but it appears (possibly incorrectly) that once an application impersonates the "right" user with sufficient admin privileges, any required data can be accessed. I've trawled through the Google Support documentation, but there is very little about scopes with regards to impersonating users that I could find. I haven't the experience building such an application to know what to look for.

My questions:

(Q) Can applications with DWD enabled do more than the scopes allow by impersonating a superadmin? If not, if one of those scopes includes the authority to change the user password (e.g. https://www.googleapis.com/auth/admin.directory.user), doesn't that mean an application can bootstrap itself and add any other, needed scopes?

Alternatively, are applications with DWD limited by their scopes, even when impersonating a super admin?

I'm not a developer; I'm a system admin with very some light/informal dev experience, so I would be greatly appreciative if you could pitch your answers accordingly.

Answer 1

The privelleges that an impersonated account has are limited in two ways

1. The impersonation can only perform requests on user's behalf within the range of the scopes authorized in the Admin consoles under Security -> API controls
2. A certain application can only use the scopes that were given to the service account when creating a credentials object

In other words:

• If you enable in the admin console e.g. the scope https://www.googleapis.com/auth/admin.directory.user.readonly for a specific service account, this service account - when impersonated - will only be able to VIEW users, not to perform any request what goes beyond the limits of https://www.googleapis.com/auth/admin.directory.user.readonly
• Even if you enable the full https://www.googleapis.com/auth/admin.directory.user scope in the admin console, but when creating the service account credentials object, you pass it only https://www.googleapis.com/auth/admin.directory.user.readonly as a scope - within the frame of the specific application, the service account equally will not be able to perform requests going beyond the scope https://www.googleapis.com/auth/admin.directory.user.readonly

The assumption once an application impersonates the "right" user with sufficient admin privileges, any required data can be accessed is confusing.

It would be more correct to say once an application impersonates the "right" user with sufficient admin privileges, any required data can be accessed - IF THE RESPECTIVE SCOPES HAVE BEEN ENABLED IN THE ADMIN CONSOLE AND GRANTED TO THE SERVICE ACCOUNT CREDENTIALS OBJECT OF THE SPECIFIC APPLICATION.

• As a general rule of thumb, you should avoid providing (both when working with and without service account) to generous scopes, it is better to provide several specific scopes, rather than one broad scope.