Within a GSuite Business Domain, how do I access contacts that have been delegated. For instance using the Google People API (https://people.googleapis.com/v1).
Delegated contacts do not have a specific group of their own, which might enable further access (https://people.googleapis.com/v1/contactGroups)
Thank you abielita for your interest in my issue! 2-Legged oAuth helps but it requires to "crawl" the contacts of each user that has delegated his/her contacts. Realizing this made me rethink my question. Google justly does not allow to pull delegated contacts. Delegating shouldn't include the consent to expose your contacts to others then the recipient of the delegation. Getting the contacts directly from the users involved via 2 or 3 way oAuth will be my path. I will close the question.
Related
GmailApp.search is great for pulling emails but what if I want to access a specific Gmail account logged in or not logged in is this possible with GmailApp or maybe some other method I am unaware of? Or am I forced to use the email address the user is logged in?
Due to security and privacy concerns, GmailApp service as well as the rest of the services provided by Google Apps Script and Google REST APIs can only access the logged-in user's data. In order to access another user's data, he/she will have to manually log in using the oAuth2 flow. As an option, you may create a WebApp that the end-user would connect to and manually authorize your application to be run using his/her data.
Th company I work for recently switched to using Team Drive and we had multiple applications that would interact with Google Drive using the Google Drive API. The API calls would be authorized using Google Service Accounts and access to specific files would be given to an app by sharing the file with the Service Account email in the same way you would share a file with a normal user. Now that we've switched to Team Drive I'm unable to grant access to the Service Account as the email address associated with it is not considered part of our organization. I've also looked into adding the Service Account as a normal user in our organization through the Google Admin dashboard, but it only allows me to create new users, not include existing ones. The only solution I've found is to enable sharing with external parties which would allow me to share Team Drive files with the Service Account, which would be considered an external party. This solution is risky and incorrect as the applications using the Service Account are part of our organization. We also do not want enable sharing with external parties in general for security reasons.
I've followed the steps described in How to access Team Drive using service account with Google Drive .NET API v3 and they work, but as mentioned above they require sharing with external parties to be enabled which we do not want.
The ideal solution would be for the Service Account to be considered part of our organization, but I cannot find a way to do this.
I've also tried delegating Domain-Wide Authority to the Service Account as described in https://developers.google.com/identity/protocols/OAuth2ServiceAccount#delegatingauthority, but as far as I understand this is not what I want as this will allow the Service Account to impersonate other users, but the reason we have a Service Account is for carrying out processes that happen automatically and which aren't associated with a specific user.
I've also followed the steps outlined here https://developers.google.com/admin-sdk/reports/v1/guides/delegation#delegate_domain-wide_authority_to_your_service_account for white-listing a specific API service through the Google Admin Security interface, but this doesn't seem to do anything, and I'm not sure what it is supposed to do as I have already enabled the Drive API for this Service Account in the APIs & Services dashboard where I originally created the Service Account.
We're using R and so I've been using the googledrive package which has functions for working with Team Drives like:
googledrive::drive_find()
googledrive::team_drive_find()
googledrive::team_drive_get(id = "team-drive-id")
I would expect to be able to see the team drive, but I guess this is not possible unless the Service Account email is a member of the Team Drive which is not possible because the Service Account (which is linked to our organization through its owner) is not considered part of our organization.
I had the exact same issue and after trying a lot of approaches, landed on the solution below (++):
Create a group in Google Workspace. You can add any external identity/email to a group, since they can be used for multiple things. So add the role account to this group.
Google has recently come out with "Trust" rules, that allow granular sharing. You can share with a group. So I created a trust rule that allowed sharing of any data source (easier than restricting who can share since file/shared drive ownership affects this rule) to only the group that contains the service account. Now external sharing is permitted, but only to the role account.
Lastly, share the drive with that role account.
++ Note that I also had followed the majority of steps above including the GCP project creation and domain-wide delegation before this portion, but was similarly stuck getting a 403 for access rights.
As an admin of G suite account, is there a way to access a domain user's G Drive data with Google Drive API, but with by passing the authorization screen?
In other words, the OAuth2.0 is setup for each user without need the user to interact with Google directly.
If possible a web code sample in C# would help.
Thanks
B
Using a service account with domain-wide delegation is exactly what you're looking for.
Service accounts are used for impersonating a user, avoiding their human interaction for authorizarion.
Depending on the scopes you use, you'll be able to define the level of access you want for your app.
You may find a sample here.
As a Reseller, is it possible for me to leverage Service Account to call Reseller API and Directory API to create new domains and manage user accounts under them without requiring user interaction/login/consent?
The End-to-End tutorial for Reseller API (https://developers.google.com/admin-sdk/reseller/v1/codelab/end-to-end) suggests it is possible. I could create a service account under my Reseller domain. Using this service account, I can impersonate a super user admin under my Reseller domain and can achieve the above.
On the other hand, when I read through the article on Authorizing Requests (https://developers.google.com/admin-sdk/reseller/v1/how-tos/authorizing), it mentioned that "All requests to the Google Apps Reseller API must be authorized by an authenticated user", which seems to suggests that some form of consent is required. Further, it doesn't mention that service account is supported.
I tried to search for similar topics in the forum and I am seeing somewhat conflicting responses. The answers range from "yes, this works" to "service account not supported with Reseller API" or "API access must be manually enabled in each resold domain".
Thanks!
I'm currently writing an auditing script that is focusing on users' gmails and need access to their message lists. I have admin access and scopes for the AdminSDK, the script will be executed by the admin.
I'm wondering how exactly to do this? I have my domain's userlist via Directory, but I can't use GmailApp with a specific user, only the current user(admin). I was also thinking about assigning a timed Trigger to each of the users and using GmailApp locally, but I can't figure out how to do that either(I don't think this is possible).
One idea that I'm working on is pinging the Gmail API using the admin's credentials via URLFetchApp, but can I get my domain's users information with this method?
What are your thoughts? Any guidance will be appreciated.
I'm currently using GAS on a service account.
While using service account, you can impersonate users in your domain and perform actions on their behalf. For this you will need to perform domain wide delegation of authority in your domain.
Here you can find documentation about domain wide delegation.
Here you can see an example, I know is on Drive but the principle is the same.
Hope this helps.