0

I have a web service that wants to access a customer's Google Workspace's list of users to check their 2FA status. To achieve this, I will use the Directory API under the Admin SDK API. This check must be performed in the background, on a regular basis, and without ongoing human intervention; a one-time setup is all that is desired.

There are two clear options to solve this problem:

  • Use OAuth2 w/ an Admin and retrieve an access/refresh token, and query the Directory API under the guise (impersonation) of their account.
    • This approach is very turn key, only requiring the admin to agree on the OAuth2 consent form to accessing the users information. This flow is ideal and what I want to achieve in terms of user experience, automated setup, etc.
    • The downside to this approach is that we're accessing the directory via the user's account. If the user is an Admin, this is fine, assuming we can prove they are actually an Admin and are able to see all of the users in the directory.
    • The other downside is that we want to see ALL USERS across all organizations/projects/etc in GCP's parlance (I'm not an expert), not just the ones the Admin belongs to or has privileges to view.
  • Create a Service Account with a role that has access to all users within all organizations.
    • This is really the preferred approach, as it's apart from any particular user and is meant for service-to-service communication.
    • The downside is that I can't seem to find an approach that is "turn key" to setup a Service Account through a consent-like process. Everything I am reading requires a lot of manual steps that the Admin must take within the GCP console:
      • Setup a new project (optional? but I guess this isolates the Service Account and its setup so it can easily be torn down wholesale).
      • Create Service Account
      • Create role for Service Account to get organizations
      • Create Admin role for Service Account to read organizations, users, etc.
      • Create credentials for the Service Account (or setup Workload Federated Identity to impersonate the Service Account).
      • Provide all the config details and credentials to my service in order to authenticate as the Service Account.
        • I would probably opt to manage my own key and have the Admin upload my public key/cert instead of downloading the private key and providing that to me in a secure fashion.

The Service Account is ideal in terms of knowing we have all the access we need, but it's cumbersome to setup. Am I missing something? Is there a way to get something like this setup via a "Marketplace app install" where the Admin just accepts our application and that application sets this stuff up automatically?

One option that ran through my mind was using OAuth2 consent w/ an Admin to obtain access to the Resources Manager API and IAM API in order to setup a project, a Service Account, a Role, etc. under the guise of the Admin, and eliminate all of the manual steps above. Would this be possible?

Thanks in advance for any advice! Happy to add clarifications where needed as well.

Jarred Nicholls
  • 66
  • 6
  • 1
    All Google user authentication requires re-authorization at some point (days/weeks). User authorization is not permanent. To use a service account requires setting up Domain Wide Delegation of Authority and that is a manual process that requires a Workplace Super Admin to enable. Because of security concerns, both methods have limitations and/or implementation requirements. Before you commit to building an app, go thru the process of user auth and service account impersonation so that you understand the features and limitations due to security concerns. – John Hanley May 31 '23 at 17:56

0 Answers0