Should I use a Service Account or an OAuth 2.0 Client ID?
I'm struggling to understand Google's documentation on authenticating for their APIs. I'm creating a basic application that will help users add and modify Google Calendar events for a single Google account (the account is shared between all users). I only need the application to access that one account, it'll never need to access any others.
It seems to me that Service Account would be best for this, but Google's documentation suggests Service Accounts should only be used for automated processes (unless I'm misunderstanding). For instance this page contains the following, describing when to use Service Accounts.
Would my application qualify as acting on the users behalf?
If so, I would want to use OAuth Client ID credentials, which will ask the user to sign in to a google account. In this case, is there a way I can guarantee they only sign in to the one account I want modified?
I can't find any decent documentation on the OAuth authentication requests to figure this out myself. If there is any could you point me there?
I'm sure I'm misunderstanding something basic here, but thank you for any help!
First off you should know that you can only use service accounts with Google aclendar api if you have a google workspace domain account.
You can then set up a calendar and a domain user that the service account can act on behalf of to control the access of that calendar.
Assuming that your application is going to preform all actions on this calendar then yes i would say that you could use a service account for this. If your app bacly has a ui with a calendar on it your just using google calendar to store the data.
However if you intend to share this calendar with the users themselves, this way they could see it within their own google Calendar account. Im not sure a service account would be the way to go.
If you want the users to be able to see it and make changes then you may want to just use Oauth2. Grant them access to the calendar and then request access to their calendar account.
Drawback to that option is going to be the verification process. You will get access to all the users calendars and your going to need write access.
If you can go with a service account you really should consider it it will save you a lot of hassle with verification.
Related
I'm trying to get some data from a user (searchconsole):
the user first grants permission on a website.
Then, the idea is to use that permission and retrieve the data with a python program that'll run on a different server.
What is the easiest/safest way to achieve that?
Should I use the same token for both servers?
or is there a solution using the service account impersonation? (I'm stuck on that one)
use the permission on the web server to add the service account as a searchconsole user?
I tried to move the token from one server to another manually, and it works, but it seems suboptimal to use the same token for both servers.
I also read the doc and all examples I could find, but didn't find my case even though it seems basic.
Should I use the same token for both servers?
Im not 100% sure what you mean by token, you can and probably should just store the refresh token from the user and then you can access their data when ever you need to. This is really how Oauth2 is supposed to work and maybe you could find a way of storing it in a database that both your fount end and backend can access.
or is there a solution using the service account impersonation? (I'm stuck on that one)
Service accounts should really only be used if you the developer control the account you are trying to connect to. or if you are a google workspace admin and want to control the data of everyone on your domain. impersonation can only be configured via google workspace and can only be configured to control users on the same domain. So standard google gmail users would be out.
In the case of the webmaster tools api im not sure by checking the documentation that this api even supports service accounts
use the permission on the web server to add the service account as a searchconsole user?
I did just check my personal web master tools account and it appears that i have at some point in the past added a service account as a user on my account.
For a service account to have access to an account it must be pre authorized. This is done as you can see by adding a user to your account. I cant remember how long ago I tested this from what i remember it did not work as the user needed to accept the authorization and there was no way to do that with a service account.
I've spent a few hours now looking through the docs + reading other SO posts, and it's still not clear to me how to simply request domain-wide credentials for Google Calendar API (for other domains; not my own).
Our current web app kicks off an OAuth flow to request Calendar API credentials for a single user; however, there doesn't seem to be a simple way like this to request credentials for an entire domain. It seems that acquiring domain-level access requires the admin to manually set up a service account and then pass that information over (https://developers.google.com/admin-sdk/directory/v1/guides/delegation) which is incredibly cumbersome.
With Microsoft's Calendar API, this is a very straightforward process where you simply specify "Application Permissions" and then the OAuth flow must be completed by an Admin to get the expected set of access and refresh tokens. For GSuite, I can find no such equivalent...
To clarify based on some comments, I'm trying to figure out if GSuite has anything equivalent to what Microsoft Graph offers as described here:
https://learn.microsoft.com/en-us/graph/auth-v2-service
The closest I've seen requires publishing to the Google Apps Marketplace; however, the documentation here seems to be quite lacking and it's unclear how things like redirect_uri for handing over credentials to the backend server are handled.
If I've missed any documentation and someone can just point me in the right direction then that would be greatly appreciated.
The best documentation for how to set up domain wide delegation to a service account is -> Perform Google Workspace Domain-Wide Delegation of Authority
request domain-wide credentials for Google Calendar API (for other domains; not my own).
You can not. The admin of the google workspace domain sets up domain wide delegation for service accounts owned by the domain.
there doesn't seem to be a simple way like this to request credentials for an entire domain.
Service account authorization is very different from Oauth2 authorization. Service account authorization is is intended for backend systems that need access to data without requesting user permission.
Oauth2 allows you to grant authorization on a per user basis. The user must grant an application access to their data by accepting the consent screen.
There is no oauth2 flow that would grant your application to all the users on a workspace domain. TBH I think thats a good thing.
Only super administrators can configure domain-wide delegation, this is done in the Google Workspace Admin console
When you enable domain-wide delegation for a service account, basically you are giving it the permission to impersonate any user within your domain
If you need to make Calendar requests on behalf your users, in your app you will need to implement impersonation, that way you will use the service account with wide-domain delegation to make the requests on behalf your users
Here you can find the documentation explaining how to set up wide-domain delegation and an example for making the API calls implementing impersonation https://developers.google.com/identity/protocols/oauth2/service-account#authorizingrequests
I'm trying to set up a google service account for Google Calendar API to create and update events for my specific calendar.
I've set up my service account, got the credential keys and also enabled the domain wide delegation. For most of the part it does work, however I can not access my specific calendar (not able to share it with my service account).
When I paste the service account email to the share textbox in google calendar settings it does not show anything to add.
This is a really frustrating blocker, so if anyone has encountered this or has any insights it would be greatly appreciated :)
You do not need to explicitly share your calendar with the service account.
If you want to create an event with your service account for your calendar, you need to set up your service account in such a way that it impersonates you.
The official Google documentation gives examples of how to perform Perform G Suite Domain-Wide Delegation in different languages. It is also important to do so in Apps Script.
Important: In your Admin console you need to Manage API client access and give the service account the necessary scope
(https://www.googleapis.com/auth/calendar.events) to create events on
your behalf.
I'm unsure where I can view the calendar I'm interacting with?
I created the project using my google work account. In the cloud console, it shows I technically have a service account for my codes authentication. Cloud console confirms I'm getting a 200 on my create event request. No event in my calendar for my work Gmail though.
You need to remember that service accounts are not you. A service account is like a dummy user, It has its own Google drive account, Google calendar account and probably a bunch more.
So when you insert something into a service accounts primary calendar its inserting into its account not yours. There is no web access to a service accounts data. You will need to do a event.list for example to see the events you have added.
What you can do is have the service account share its calendar with you and then you will be able to see its calendar in your google calendar web view. If memory serves you have to add it as an acl rule. You could also share your calendar with the service account and then it will be able to update that.
Useful links Sharing calendar my tutorial on service accounts
Now as for Google for work. You are going to have to add the service account to that somehow grant it access to the Google for work calendar. I dont have access to that so cant be of much help.
I have an application using Google Drive that must (a) not require user login and (b) populate a document that authorised users can view.
Because of this it appears that using a regular account as a service account is my only option, as described here https://developers.google.com/drive/web/service-accounts
Use regular Google accounts as application-owned accounts
You may create a regular Google account like any user would, by going
through the Google account sign-up flow or by creating an account on
your Google Apps domain. Make sure it is then never used by an actual
person but only by your application.
To be able to access the account’s Drive programmatically you need to
manually go through the OAuth 2.0 web-server flow once and then store
or hard-code the user’s credentials, such as the refresh token, to be
able to programmatically access its Drive. For more information about
the web server flow for Drive, see Implementing Server-side
Authorization.
While it discourages user access, it doesn't ban it. However I am confused by the line
you need to manually go through the OAuth 2.0 web-server flow once and
then store or hard-code the user’s credentials
There doesn't seem to be a documented way to do this (yes, I have searched) - could someone step me though it?
You don't use a regular account as a service account, these are different things. Each one is a type of application-owned account.
The regular account is just a normal Google account that your application uses. Since regular accounts require the manual authorization step (going to the browser, logging in to Google and authorizing your app), you need to do this manually the first time and then save the token. There's some examples in this page. After you save the token, your app can authorize itself without your intervention.
The service account is an account that is not associated with an user and that do not require manual authorization. You can create a service account in the Developers Console as described here. With this type of account, you use a private key file to authorize your app.
Unless you need access to the web interface of the account that will manage your files (for example, to buy more storage), I'd recommend using the service account, since it doesn't require the manual step.