regarding Out-Of-Band (OOB) flow Migration Guide

[Lawrence Kalinowski]

https://developers.google.com/identity/protocols/oauth2/resources/oob-migration

Hi - I'm a little concerned.

We presently have a Desktop oauth flow application we use to download data from Google Ads API. We attempted the service client switch, but honestly it doesn't work and we haven't figured out why. 

When I login to console to check for any redirect_uri (OOB footprints) information. I don't see any associated with the client id. Unfortunately the Oauth consent screen is no longer available. It requires some verification steps (including youtube videos) which we have not completed.

When I sniff our applications network traffic I see no redirect_uri instructions AT ALL in any communication with Google. Which makes me think i won't know if we are ok until the currently valid tokens expire.

I suppose my question is:

Will the Desktop Oauth flow our application uses to contact Google Ads API stop working:

1. On October 3, 2022
2. or once the refresh token expires?

 

Please note, the java lib we use to communicate with Google is:

com.google.api-ads

artifact Id: google-ads

version: 19.0.0 

I would be thrilled to share specifics with someone in a position to see behind Google's dashboard and tell me if we are vulnerable to a service halt  on 10/3/2022.

Thanks much - Lawrence Kalinowski

[Google Ads API Forum Advisor]

Hi Lawrence,

It's good you reached out to us, you have been on 3 difficult trips, so let me address each one. You are concerned your refresh token that was generated via an OOB copy/paste response code will expire on October 3 and we have the same concern, although we cannot give you certainty. When you tried to generate another refresh token you encountered an app verification requirement which blocks you from generating an access code. To get around this you tried to make a service account and the prerequisites to use a service account with Ads API are extremely heavy. 

To get you up and running fast you may want to do one of these options:

1. If you can click 'Advanced' on the Oauth error screen on the bottom right and authenticate anyways, then this is the simplest option. If it's available then you probably have an Exceptions to verification requirements and can continue to generate refresh tokens by clicking past the warning
2. You can Configure a Google API Console Project for the Google Ads API, with the same developer token, as long as the new project is exempt you should be good to go.
3. Go through Oauth verification - How to verify: OAuth API verification FAQs - Google Cloud Platform Console Help General information: Unverified apps - Google Cloud Platform Console Help.
4. Make an internal app, only your Google Workspace domain accounts will be able to access through this internal app.
5. Service accounts -  with a Google Workspace domain account, delegate domain-wide authority to your service account and only being able to access accounts that have a user in that Google Workspace and deal with the Security concerns.

Note that a  Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days. Feel free to reach out to us.

Regards,

Aryeh Google Ads API Team

 

ref:_00D1U1174p._5004Q2efNUO:ref

[Lawrence Kalinowski]

disappointing interaction with the verification group.

Video filming of user consent screen seems to be an issue.

I'm confused because this is not an externally hosted process anyway; so testing is impossible for any external parties. The idea that this access would be disrupted because we cannot supply a user consent screen or allow network access to test seems bonkers. Surely we are not unique in our use of backend processes to collect data for decision making.

Maybe, I am using Google meta language to describe concepts incorrectly.  How would Google describe a scheduled reporting process we host internally that uses the Google APIS API developer key to scrape data for our database?

Perhaps if you provide me the appropriate lingo I can shortcut my communication with the verification team.

thanks

[Google Ads API Forum Advisor]

Hi Lawrence,

Thanks for getting back to us.

Kindly note that for the OAuth2 desktop app flow, you can persist a refresh token (which never expires) to obtain a new access token whenever necessary. When using one of our client libraries, you can authorize your app by filling out a configuration file. Since you are using Java, then you may use our latest client library which already migrated from OOB to redirect URL, and for local testing that's compatible with the default configuration in our client library examples, use http://127.0.0.1. You may also add a port number to your redirect URI to restrict usage to a specific port. If the port is not set, an OAuth client can redirect to any port. For Desktop app clients, you will still use a loopback IP redirect, but the URI is not explicitly configured in the Cloud console.

With regards to verification, our documents says “We recommend that all apps undergo the Google OAuth verification process as soon as possible to avoid any business interruptions.”

 

For information on OAuth Verification, and how to verify your projects, please refer to the below links:

• How to verify: OAuth API verification FAQs - Google Cloud Platform Console Help
• General information: Unverified apps - Google Cloud Platform Console Help

However, if your app is going to be used in any of the following scenarios, you do not need to submit it for review:

1. Personal Use: The app is not shared with anyone else or will be used by fewer than 100 users (all of whom are known personally to you). Note that your app will be subject to the unverified app screen and the 100-user cap will be in effect.
2. Development/Testing/Staging: If your app’s publishing status is set to “Testing” and not “In production”, then you do not need to submit your app for verification. Note that your app will be subject to the unverified app screen and the 100-user cap will be in effect. Learn more about Publishing status.
3. Service-owned Data Only: The app only accesses its own data (using a Service Account), and not user data (linked to a Google Account).
4. To understand what service accounts are, see Service accounts.
5. For instructions on using a service account, see Using OAuth 2.0 for Server to Server Applications.
6. Internal Use: The app is used only by people in your Google Workspace or Cloud Identity organization. Note that your app will not be subject to the unverified app screen or the 100-user cap if it's marked as Internal.
7. Learn more about public and internal applications.
8. Learn how to mark your app as internal in the FAQ How can I mark my app as internal-only?
9. Domain-wide Installation: The app is used only by Google Workspace enterprise users. Access will depend on permission being granted by the domain administrator. Google Workspace domain administrators are the only ones that can add the app to an allowlist for use within their domains.
10. To learn how to make your app a Domain-Wide Install, see My application has users with enterprise accounts from another Google Workspace Domain.
11. SMTP/IMAP/WP: The app is used to send emails through WordPress, or similar single-account SMTP plugins.

 

Let us know how this goes on your end.

Regards,

Yasar Google Ads API Team

ref:_00D1U1174p._5004Q2efNUO:ref

[Jim]

sounds like we don't need to verify. which is good.

i can certainly create (and reauthenticate) desktop apps.

assuming the following:

a. accessing 25 accounts nightly

b. backend process using ads.properties paradigm via Google's JAVA v11 libs

 If i do this will the desktop client stop working periodically and require reauthorization or should i expect it to persist forever.

thanks, Lawrence K

[Google Ads API Forum Advisor]

Hi Lawrence,

Thanks for getting back to us.

With regards to persisting refresh token, based on this documentation, a Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days.

Also, if you set the publishing status to "Testing" so the refresh token expires every 7 days and receives an “invalid_grant” error. Note that OAuth2 access expires after a limited time, an OAuth2 refresh token is used to automatically renew OAuth2 access.That being said, please go to the Google API Console and navigate to the OAuth consent screen and then change the publishing status to “In production” to avoid the refresh token expiring in 7 days. If you have further questions on the OAuth expiration, we highly suggest that you reach out to the Google API console support team via this API Console Help link. 

Regards,

[Jim]

appreciate it. thank you