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.
Related
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
I'm working on development of web application that communicates with GSuite services (e. g. Gmail and Google Drive). Bunch of people currently use my application. I have 2 OAuth 2.0 applications created in my GSuite organization: one used for development and testing purposes (let it be MY_DEV_APP) and another one for public usage (let it be MY_PROD_APP). Recently I've got a message from Google team that my apps should be verified till the end on May 2019. So I went through all the requirements described in documentation and made changes in order to meet them. After that I sent MY_PROD_APP application to verification but not the MY_DEV_APP application. MY_PROD_APP gets verified and is still used publicly. However MY_DEV_APP application left unverified and now I see that all the scopes are removed from it (looks like it was disabled by Google)
so that I can't use this application anymore.
As documentation states:
An unverified app is a web application or Apps Script that requests a sensitive OAuth scope, but hasn't gone through the Google verification process. Users of unverified apps or your test builds might get warnings based on the OAuth scopes you're using. This is to protect users and their data from deceptive applications.
OAuth 2.0 application can be created for internal usage only in GSuite or with limited access AFAIK. But currently I can't figure out how can I do this. Could you please provide detailed manual how to do this? How can I create OAuth 2.0 application in GSuite for internal usage only without mandatory verification?
Creation process of G Suite application for internal usage (inside your organization) only is almost the same as for the regular application. All the steps for creation and publishing G Suite application is described in G Suite Marketplace Guide. In order to create G Suite application for usage inside of single organization and omit verification process you should set Visibility option value to "My Domain" (application will be only available to users inside your domain) during configuration of G Suite Marketplace SDK as described here. This option can't be changed after saving configuration so it should be set during initial setup.
After publishing your internal application it can be found in G Suite Marketplace section where all applications for your domain are located.
Here is a short list of steps for creating of G Suite application based on information from G Suite Marketplace Guide:
Create new project in Google API console. Set name, project ID (project ID can't be changed after project creation and it should be unique) and project location (as a rule this is current GSuite domain and it can't be changed at this point).
Configure consent screen as described here. Here you can choose required scopes for Google APIs and authorized domains. Set "Internal" Application type so that only users with a Google Account in your organization can grant access to the scopes requested by this app.
Setup OAuth 2.0 client ID. After saving the configuration you will see popup with client ID and clien secret. Copy and save them somewhere. Please note that these value will be later available under creadentials tab for given application (OAuth 2.0 client IDs > Client ID for Web application item) at any time.
Setup service account key. After that JSON file will be downloaded where you can find private key and other information that you need to use your application.
Add APIs & services that you application use (e. g. Gmail API, Google Drive API). G Suite Marketplace SDK is required here.
Setup G Suite Marketplace SDK and publish you application as described here. Choose "Public" Visibility option to allow your application to be found by and used by any admin from the G Suite Marketplace. Otherwise you can select "My Domain" visibility (also known as Private visibility) that indicates that only admins in your domain can find and install the app from the G Suite Marketplace. If Enable individual install is also checked, then single user can find and install the application as well as well as it can be installed by organization admin.
I don't know the version of the G Suite account you have but I would suggest to create an App Maker application if is for internal use since no one can access if is from outside the domain.
To get your application verified I would suggest to send a verification request from the consent screen of your project, the first time you may send the verification without the scopes your application needs then it should be approved for you to add the scopes that your application use in order to get these verified one more time. Usually since the very first verification request by adding all the scopes you should have your account verified.
If you are still having problems by getting the verification I would suggest to contact the G Suite Support and request to speak with the API team, they don't have direct access to approve or reject the applications but will be able to help to provide you a guideance or may request internal help for you.
To know more about Google App Maker you can check here https://developers.google.com/appmaker/?hl=es-419 and https://gsuite.google.es/intl/es/products/app-maker/.
I hope this information is still useful. Greetings.
We already have a web app that integrate with differente Google services. Right now, you can loguin using a Google account, can import a contact lists from any Google account, and can sync a Google Calendar with our Calendar in the webapp (We implemented all of this using OAuth 2 and invoking the GoogleApi with a REST Client).
We are now trying to publish this app in the GoogleApp Marketplace, but we are failing to comply with the "Use one-click single sign-on" rule (https://developers.google.com/apps-marketplace/practices#5_use_one-click_single_sign-on).
We are believing that the problem is we the way we are solving the fact that we need offline access for all the integrated users in the app. Right now, the only way we found to get the refresh tokens for them, was starting the OAuth2 process with the parameters access_type=offline&approval_prompt=force, but this forces them to enter their credentials.
We aren't using the 'Google+ Domains API', and we are starting to believe that we should. Is the use of this API mandatory for complying with the "Use one-click single sign-on" rule?
Thanks,
Well, we finally figured it out. We had to use the Google Admin SDK in order to implement SSO. We had some troubles with the scopes, but after we polished that, everything seems to be working OK.
I'm in the process of learning how to interface with OAuth. I'm using a fusion table as the back end of a database and then using google apps scripts to interface with that database. Parts of the apps script will run of time scheduled triggers while other parts will be published as a webApp. I've run into some other OAuth issues (see thread link below), but this question is much more fundamental. When reading the Google API OAuth literature, it describes different OAuth flows and I don't know which one my program is. Is my application a "web server application", "client-side", "service account" or what.
Google API OAuth info: https://developers.google.com/accounts/docs/OAuth2
Other Thread: Getting Google Apps Script to Authorize Fusion Table API
First of all, the fact that you install a trigger to run a certain function at certain times has no bearing on which Oauth Flow you should use.
Oauth is used to allow Users of your App to grant your App permission to access certain resources that normally only they would have access to.
When you include certain API calls in an App Script, Google Apps automatically presents the user with a Dialog asking for "Authorization" to use these resources on their behalf.
Therefore, in your use case of an App Script as a Front-End to a Fusion Table, you would not need to use Oauth to get Users to Grant permission.
You can Publish your Script to "act" as the User or as the Script Owner.
Currently Google is migrating their old Google Data API to the new Google API.
When we do API queries over the old Google Data API, we usually use Zend Framework and the given consumer key/secret to do the authen/autho, which is fine.
Question is, is it possible to use the given consumer key/secret (from the Google Apps Marketplace listing) and the new OAuth 2 Library to call the API? What I have been having is the error message redirect_uri mismatched issue and obviously Google Apps Marketplace provides no way to change this value. Even though they had provided a link for us to go to the API Console from the listing page, I cannot see the OAuth 2.0 options in my API Access page at all.
Did I missed out anything?
If let's say I need to use the Google Apps Admin Settings API, does it mean I need to separately create a new OAuth 2.0 API Access in the API Console, then, when I need to access user data, I need to do the Auth flow again using this new consumer key/secret/redirect? I can't set this permission in the Listing Manifest? (Not supported?)
Thanks for the clarifications!
Google Apps Admin Settings is not yet migrated to the new google-api, AFAICS. Check out this list : http://code.google.com/p/google-api-java-client/wiki/APIs ;
you can however use the new google-api client libraries but you have to roll your own XML model for the given API, it is not so hard, I did a similar thing for the Contact API;
The consumer/key secret can be re-used normally if it is sufficiently scoped. A related project for your market app is automatically created in the Google Api console from what I remember..