We are working on a Migration App for Google Drive (Google Workspace) and are relatively new to Google APIs. I read that administrator need to grant domain-wide delegation of authority to third-party and internal applications so that they can access users' data such as read Google Drive files.
Control API access with domain-wide delegation: https://support.google.com/a/answer/162106
For delegating domain-wide authority to service account, a super administrator of the Google Workspace domain must complete 6 steps as described in the documentation link below:
Delegating domain-wide authority to the service account: https://developers.google.com/identity/protocols/oauth2/service-account#delegatingauthority
As I understand these 6 steps have to be manually performed by Super Admin of the Google Workspace. I would like the super administrator should be able to do these steps easily and quickly. Can this process be automated or guided using some sort of Consent Grant screen in Web Portal.
Instead of using service accounts, can we use OAuth 2.0 Client ID (created within third party app's Google workspace) and consent of Administrator to provide delegated access of their Google Workspace to third party application.
I am asking this because I would need to get list of all users in that Google workspace and have read access to their google Drive files.
Directory API: Authorize Requests" using Admin SDK: https://developers.google.com/admin-sdk/directory/v1/guides/authorizing
Scope for only retrieving users or user aliases: https://www.googleapis.com/auth/admin.directory.user.readonly
Thanks!
I am afraid it is not possible at this moment to manage the domain wide delegation settings through APIs or any different way to automate the process. The Google Workspace Directory API is the only possible way you can use to manage Admin console related settings using the Google APIs, however there is no API method that can make changes like this.
Now, about this:
Instead of using service accounts, can we use OAuth 2.0 Client ID (created within third party app's Google workspace) and consent of Administrator to provide delegated access of their Google Workspace to third party application.
The only possible way is by adding the application to the domain wide delegation settings, but again, only the admin can add the app manually to their Google Workspace admin console.
Since this is a feature that is not available yet, you could submit a feature request in the Directory API to suggest this as an actual feature and maybe Google can make it available in the near future.
Reference:
Admin SDK: Directory API
Feature request
Related
Struggling to get a difinitive answer on this so would appreciate any help.
We have a Python Script that pulls data from a piece of hardware and uploads it to a Google Sheet using the drive / sheets api.
We also have a global policy in the top level OU to Restricts sharing outside of the organisation.
If you create a seperate OU in GAdmin console where external sharing is allowed and move the Account assosiated the with Gdrive / Gsheets to this OU, everything works. You share the sheet with the service account as part of the process.
This also means however the owner of the account can share other data using the account. We'd like to lock down the account , but I'm not sure it's possible as you can't whitelist service accounts, only other Gsuite domains.
There is also a point discussed about using the option to grant the service account "delegating domain-wide authority to the service account for a particular API scope (i.e. Drive) -" but from a security point of view that option that doesn't seem optimum either.
Is there any other way to achieve the access where by you can restrict sharing only with the service account and organisation accounts.
The below describes the process:
https://towardsdatascience.com/accessing-google-spreadsheet-data-using-python-90a5bc214fd2
Similar question previously.
Whitelisting Service Account for Google Drive Document Access
I'd like to create programmatically via API a new Account for accessing my Google Cloud Platform.
I'm already doing it for GSUITE (provisioning users via OAUTH), is it possible to do the same also with Google Cloud Platform?
Is it possible to do it for an "non-google" external account maybe with an invitation on the email?
Having already the setup for OAUTH in GSuite, is it possible to use the same token / account to perform also this operations (maybe assigning more scopes)?
Are this API (https://cloud.google.com/iam/docs/granting-changing-revoking-access) the only available?
Updating the IAM policy is indeed the only way to use an API to grant access on a "pure GCP" level.
However, you can give a role in a project to a Google Group (or a few, if you require different access levels), and then simply manage the group using the GSuite Admin SDK.
I am attempting to get get a Ruby on Rails project that uses the Google AdWords API.
What I did so far, following the steps in this guide:
I created an AdWords Manager account.
I created a test account that is part of the AdWords Manager account.
I set up the Ruby client library in my Rails project.
I then attempted to set up OAuth2 authentication with the example code from the guide.
However since the guide was written (and the video version of the guide was made) it seems that the interface has changed. I am able to create a Client ID client_secrets.json-file, or a Service Account .json file. I am able to export these and read the settings from .
I added the required settings, using an OAUTH2_SERVICE_ACCOUNT .json file.
Now, when attempting to connect, I get back the AdwordsAPIException AuthenticationError.NOT_ADS_USER.
I therefore know that the actual authentication works. However, the authorization does not.
How can I turn on AdWords API support for the oAuth credentials from my google accounts? The Google Credentials Console lists many APIs that you can turn on, but the AdWords API is not in there. The AdWords guide does not mention turning on an API at all, and only tells you to create a new Credential.
What is going on here?
The Adwords API does not need to be added to your project in the Google Cloud console (it's always enabled)—as indicated by the error message, the actual problem lies in the fact that your service account does not have access to any Adwords accounts.
As a matter of fact, the only way to use service accounts to authenticate against the Adwords API is when you're also using a G Suite domain (see the corresponding documentation, section "Prerequisites".
If you have a G Suite domain, you'll need to
Enable "G Suite Domain-wide Delegation" on your service account key
Add the project ID of the Google cloud project to your G Suite domain's authorized API client list
Use your service account to impersonate any user from your G suite domain that has Adwords access
As you can see, it's quite an involved process. My recommendation (that is shared by the above article) is to use an OAuth2 installed application flow for any user that has Adwords access. This requires to store the obtained refresh token on your end, but is more flexible (and arguably safer) than a delegation-enabled service account and easier to set up.
With the changes to third-party access protection for Google Sheets, calls to the Visualization API now require OAuth credentials unless Spreadsheets are shared to "anyone who has the link can view". (Google Developers Blog Post)(Google Charts Authorization)
Does this still apply to Spreadsheets that are shared to "anyone at domain with the link can view"? If so, how would I get a OAuth credential without prompting the end user for access to their Drive or Spreadsheets? Is it possible to pass a credential using a service account? We do not want to prompt every user that uses the application, since it has been authorized by a Google Apps Administrator and executes using service accounts.
Does this still apply to Spreadsheets that are shared to "anyone at domain with the link can view"?
It is stated in this documentation that:
Google Sheets requires end-user credentials to access private
spreadsheets via the Google Visualization API ("/tq requests")
but Take NOTE that:
Spreadsheets shared to "anyone who has the link can view" do not
require credentials. Changing your spreadsheet's sharing settings is
much easier than implementing authorization.
So if your spreadsheets is shared to "anyone who has the link can view", you are not affected by this update beginning September 14, 2016.
For more information, check this thread.
The "Anyone at domain with the link can view" still requires OAuth credentials, since the application is accessing non-public data. If you are using domain-wide delegation and service account impersonation, you can simply generate an access token in your backend and pass it in the requests to the /tq endpoint.
I am creating an iOS app for internal use. We have a Google Domain. As part of the functionality of the app, I want to be able to search for all users in that domain. This can already be done in Gmail, the Apple Mail app, and others.
I found that you can use the Admin SDK for users.list to do exactly what I want to do. I created a Client ID for the iOS app and authorized my app to perform users.list.
However, now I get a permissions error for users who sign in with OAuth2:
I found that you can create a service account to make API requests on your behalf if you delegate it to have the authority. I'm not sure if this is what I want to do since this seems more like something for a secure server to do rather than an app. I'm also not sure how this integrates with a user (from our domain) who signs in with OAuth being able to list our users.
Is it possible to list/search the users in a Google domain purely through OAuth / frontend app?
Aside from caching your own list, I think there are two ways to give users the ability to list all users:
A. Undocumented call to this GAL API:
https://www.google.com/m8/feeds/gal/your-domain-goes-here/full?alt=json (source). You can test this in the Google OAuth Playground by selecting the scope for the Contacts V3 API or using the string https://www.google.com/m8/feeds/.
B. In the Admin console, create an "all users" group. Assign to a newly created Admin Role. Grant the admin role "read" in Privileges > Admin API Privileges > Users > Read (checked).