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
Related
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.
I have a web app which sends emails (gmail) in name of my users
When a user registers, she supplies gmail account and password. Also she has to enable access for Less Secure Apps (I recommend to create a new account for this)
Then I can open a gmail session
session = Session.getInstance(props, new javax.mail.Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(user.getEmail(), user.getPassword());
}
});
and send emails on her behalf.
Unfortunately this is going to stop working next 30th May, when Google will allow only OAUTH2 access
I have followed Java Quickstart for Gmail API and I have code up and running for sending emails with OAUTH2: enable gmail api, create an application on google cloud platform, grant send permission, oauth2 client id credential created...
The problem I have is I can't see a way to automatize this task because when creating an authorized credential, a consent screen displays on browser and you have to select the account to be granted manually (maybe because my app in google cloud platform is still pending to be reviewed)
Is there a way to infer the gmail account you want to access from the credentials file (client_secret.json)? Is there a way to automatize this?
No, or yes. It depends.
The whole point of OAuth2 is to improve security by working with authorization tokens rather than asking for user credentials. To do this the user has to consent to the app's access request, and thus the OAuth consent screen cannot be bypassed. This is
explained in Google's documentation. It's not related to your app's review status but rather it's the way OAuth works.
You can still work in a similar way, though . Instead of asking for username and password upon the user's registration you can redirect them to the OAuth consent screen so they can authorize your app. Make sure that your app is requesting offline access type and then you can retrieve an access_token and a refresh_token. These will essentially work as your credentials and you can use the refresh token to generate new access tokens when needed without having the user go through the consent screen each time.
The refresh token doesn't have a "natural" expiration so you can keep using it indefinitely, but there are a few scenarios where it will become invalid, such as it not being used for six months, the user changing passwords (if using Gmail scopes), the user manually revoking access, etc. In these cases you will need to direct them to the consent screen again to reauthorize your app.
In this sense, your app can still work automatically without user input except the initial setup, which you already had to deal with when they supplied you with their credentials. The refresh token expiration can even be compared to what you had to do when the users changed their passwords in your current workflow.
One exception to this are service accounts. If you and your users are part of a Google Workspace domain you can delegate domain-wide access to it, then the service account will be able to access user data without any manual input. Of course, this is because as the domain administrator you pretty much own all the accounts under it. But if you're working with a publicly available application you will have to deal with the limitations I mentioned above.
Sources:
Google's auth overview
Using OAuth 2.0 to access Google APIs
OAuth 2.0 for web applications
The OAuth consent screen
As Google does not support "client_credentials" grant in OAuth, how can I access the users mailbox on behalf of him (machine to machine)?
My Java application would be able to store any user credentials in a secure place.
Thanks for a pointer :)
UPDATE
Thank you for your response. But I am not sure, if this explanation solves my use case. Let me better describe the environment:
Since several years, I have a background Java task which runs without user interventions:
The user enters once his normal username and password credentials which are saved in a secure place.
The Java task regularly connect (thru IMAP) to the users mail box (e.g. john.doe#gmail.com) thru the Java Jakarta Mail API to read and process any new incoming mail from the users inbox.
To support a more modern authentication, I would like to switch the authentication to OAuth 2.0. The used Jakarta Mail API already support the IMAP connect thru the use of an access token, so I only need to add the code to ask the authorisation server for the access token.
Questions:
Is this possible with Google OAuth?
Which OAuth grant type must be used? First I thought "client_credentials" should be used, but Google do not currently seem to support it.
Thanks!
Domain-wide delegation lets you do that:
In Google Workspace domains, the domain administrator can grant third-party applications with domain-wide access to its users' data — this is known as domain-wide delegation of authority. To delegate authority this way, domain administrators can use service accounts with OAuth 2.0.
This is obviously a very powerful capability, so make sure to:
protect the service account appropriately
only grant the least set of OAuth scopes that's necessary.
Note that domain-wide delegation doesn't necessarily require service account keys.
I want to send emails from my gmail address through my own server. I'm using nodemailer and using account credentials is flaky, and often times doesn't work and leads to this thread
I've implemented everything on that thread many times, and still it's flaky, and also I know OAuth2 is the way to go.
I have a project with cliendID and clientSecret in google developer console, as you can see:
But how do I get an access token WITHOUT any browser interaction?
I seem to be missing something trivial here ...
I've went through all google tutorials and docs I could find about OAuth2, tokens, and APIs, but all guides go through the browser in one point.
Go to the OAuth Playground, click the cog on the top right, check the Use your own OAuth credentials and insert your clientID and clientSecret.
Then select the Gmail API v1 scopes you want in the list to the left and follow the outlined steps and you will get an access_token and a refresh_token.
Google Oauth2 actually all Oauth2 implementations I am aware of require that a user grant an application access via a web browser.
There is an alternative type called service accounts this is more like oauth1 service accounts are preauthorized. You can grant a service account access to your google drive by sharing folders and files with the service account like you would any other user. Because they are preauthorized there is no browser window pop up with service accounts.
You can only user service accounts with Gmail if you have a Google domains account Gsuite. The admin can go in and grant the service account access to the Gmail account in question. Perform G Suite Domain-Wide Delegation of Authority
If this is a normal user Gmail account you cant use a service account. You will have to use Oauth2 popup the request and save the refresh token so that you can gain access at a later date.
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.