Search code examples
oauth-2.0google-apigoogle-drive-apigoogle-oauthimpersonation

Access Google Drive of ALL Users in Customer's Google Workspace Domain using Admin Login

I am working on a Google Drive Migration project for migration of Google Drive Files to different destinations.

How do I access a user's Google Drive files of a different (i.e. customer's) Google Workspace.

I read about 2-legged OAuth and 3-legged OAuth https://support.google.com/a/answer/2538798?hl=en

It says "Traditionally with Google, 2-legged OAuth is for administrator-managed applications, in that an administrator grants access to an application to access data for the Google service for ALL users in their domain. Common data requested for access include: Groups Provisioning, User Provisioning, Calendar, and Contacts."

Can I use 2-legged OAuth approach and ask Admin to sign-in and grant permissions to access Google Drive Files and Folders for ALL users in the domain.

If yes, how do I impersonate or access a particular user's Google Drive files using Drive APIs such as: https://www.googleapis.com/drive/v3/files/root or https://www.googleapis.com/drive/v3/files?q={fileid}+in+parents

Thanks

Solution

  • Even Super Admins of a domain cannot access all users' files by themselves, so you can't just have an administrator log in to your app via OAuth to gain access to the entire domain. The article that you linked says that the 2LO approach has been deprecated and you cannot use it this way anymore:

    Important: OAuth 1.0 2LO was entirely deprecated on October 20, 2016. The easiest way to migrate to the new standard is to use OAuth 2.0 service accounts with domain-wide delegation.

    Instead, you need a Service Account that has been granted domain-wide delegation on your target domain. Here's an overview of how it works:

    1. Create the GCP project that your migration app will use.
    2. Enable the APIs that you will use. It should be at the very least the Drive API since that's what you're looking for.
    3. Configure the OAuth consent screen of your project with the proper scopes and publish it.
    4. Create a service account and setup its credentials.
    5. Once your app is published, you can get the ID of the service account that you created and ask the other domain's admin to grant domain-wide delegation to it. This means that the other admin will add your service account's ID to their list, along with the allowed scopes.
    6. Once the other admin has granted domain-wide delegation to your service account you can call your authorized APIs and impersonate their users. The exact syntax depends on your language but here are some examples.

    Essentially, you need to gather a list of the users, then impersonate them one by one with your service account. With each impersonation you are acting as if you were the user so you can just call the Drive APIs normally to list the user's files and migrate them as needed. Without knowing your language of choice I cannot provide a specific example but I hope this gives you a general idea of how it works.

    References: