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
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:
Create the GCP project that your migration app will use.
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.
Configure the OAuth consent screen of your project with the proper scopes and publish it.
Create a service account and setup its credentials.
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.
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:
Domain-wide delegation
API access with service accounts
Related
I have created a microsoft chat bot, and have set up the /adminconsent workflow, where another application has given admin consent to my bot to act on behalf of them.
#shawn-tabrizi wrote a great article about how to remove my own bot's access to their application from the UI, but I can't find a way to remove access using Microsoft Graph.
Any help would be appreciated!
I believe you're looking for Delete an appRoleAssignment granted to a service principal:
App roles which are assigned to service principals are also known as application permissions. Deleting an app role assignment for a service principal is equivalent to revoking the app-only permission grant.
It is possible to authorize some MS apps using OAuth and login form. If the user logins and allows the permissions the app wants then as a developer you can read (and write) some data via API.
Is it possible with https://botframework.com? I don't want my clients to have to write down the client_id and client_secret in my administration. I just want them to give me permission via logging in and let me download this data.
I've read MS docs about OAuth and have seen that the possible scopes doesn't include the bot platform.
To demonstrate what I mean here is a demo application from the docs.
I recommend you to check AuthBot.
AuthBot is a .Net library for Azure Active Directory authentication on
bots built via Microsoft Bot Framework.
In short, when using AuthBot, your users will receive a link that they will open and perform the OAuth flow. The users won't have to write the credentials in the bot (which could be a security concern) and instead will be done in the MS login page. Then a callback (already provided by the library) will be called and the conversation with the user will be resumed.
You can also check AzureBot as an example of a Bot that uses AuthBot and that retrieve information only available if you are logged.
Does Directory API support authentication with OAUth2 Service Accounts flow?
I tested the serviceAccount.php google-php-api-client example using the scopes https://www.googleapis.com/auth/admin.directory.group and https://www.googleapis.com/auth/admin.directory.user and it didn't work.
You need to authorize the service account client ID to access the given API scopes in the Google Apps Control Panel. See the step as described in the Drive API docs, just sub in your Admin SDK scopes.
Note that IMHO, there's very little advantage to using a Service Account with Directory/Reporting APIs as you still need to impersonate a user who has super admin (or proper delegated admin) roles in order to perform and API calls. To me it makes just as much sense to just get a 3-legged OAuth 2.0 refresh token which supports offline from the admin. 3-legged can be done entirely programmatically where-as Service Accounts require the manual step above.
Short answer: Yes. #emilylam question comments hint the error.
I'm making an application wich allows the admin to manage the files of users in the google apps domain.
Since the docList api is deprecated I used the Drive api.
How I can create a Drive service as another user while logged in as admin?
Some people suggested to use the OAuth consumer key.
But I don't know how to implement this with oauth-2.0.
You might want to check out this post: Google Drive service account returns 403 usageLimits
I used OAuth2 and a service account to accomplish pretty much the same. Keep in mind you need to use the API Console to setup your environment and ensure the service account is added to the Google Apps domain with the proper scopes to allow access.
We want to use Google Doc API to generate Document (In our own business account) when our end users do some actions on our site.
The problem is that we've tried to implement the OAuth 2.0 protocol, as suggested in the v3.0 protocol documentation. The apiClient::authentication method do a redirection. This is a major problem because our users doesn't know the access to our own business account.... and we don't want to give them access anyway ;)
(In other word, we're not creating an application that allow our users to edit their own data, but to interact with our data, like a database.)
I've read that the point of OAuth 2.0 was to avoid that we manage the credential of our users. I'm personally O.K. with the concept, but in our case, we don't want to get authenticated in the google account of our users ...
So, what would be the best approach to get a valid authentication without any interaction from the end user ?
What you describe is not how 3-legged OAuth was designed to be used.
3-legged OAuth is all about delegated authentication where a user (who knows his password) can grant limited and revokable resource access to application. That application never sees the user's password. There is a bunch of work involved to safely allow the application to impersonate the user.
What you probably want is to use the (2-legged) OAuth flow, where the consumer_id/consumer_secret credentials are embedded in your application. Here your application is not impersonating your end user and there would be no browser redirection involved.
Here's some further info on using 2-legged OAuth in Google Apps:
http://googleappsdeveloper.blogspot.com/2011/07/using-2-legged-oauth-with-google-tasks.html
And this is a good description of 3- vs 2- legged OAuth:
http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/
You will need to use a SERVICE ACCOUNT. Basically you are hard coding access to this account into your server application. Then you use sharing to give access to the to account for the content you want. For example you can share a Google Doc or an Analytics profile with the SERVICE ACCOUNT.
Here is a complete example implementation of setting up a service account, logging and and then using it.
Updated 2018-12-12: https://gist.github.com/fulldecent/6728257
Why not get one OAuth authorization for your business account and have all users use that account. Since it sounds like you want everyone accessing the data for one account, the details can be hid from the end user.
The access token would be shared by all users and they would all hit the same account back end without any authorization for each user's own account.