Problems moving from the Refresh Token (Installed app) flow to Service Account flow

[Sheeds]

Hi,

Our application currently uses the Refresh Token mode of authentication to the AdManager API. An email recently instructed us that "OAuth out-of-band (OOB) flow will be deprecated on October 3, 2022". We've read this as meaning we need to move to the Service Account flow (as web-flow doesn't seem appropriate for our application)? Is this correct?

We have followed the instructions at https://developers.google.com/ad-manager/api/start in a .NET test application as instructed. Even created a new service account altogether exactly as instructed then added that to our network.

The example from the video works as expected but only accesses the networkService and that works ok. However the code example which calls on the InventoryService is not working, no results are returned - no errors produced and nothing in detailed soap logs (unless we have malformed criteria which produces an error). Summary soap logs recognise a call but report no failure.

We have proven that the creds (the JWT) are working by extending the example to call on the CustomFieldService and we can get results for that. Other services we've tried like OrderService for orders we know exist are failing to return results and no errors or soap logs resulting?

If we revert the test application to use the refresh token flow, all these queries work ok. We've played with the service account user in AdManager, making it an Administrator (video only suggests Trafficker for those cases) which got the CustomFieldsService working for us, but it appears other entities we don't have access to? We've tried adding All Entities to the user's teams as well to no effect.

In summary, my questions are:

1. is it true the refresh token flow is being deprecated or have we been mislead by that email?
2. why would we only have access to (seemingly) some entities and not others with the service flow? 

Thanks

Mark

[Ad Manager API Forum Advisor]

Hi Sheeds,

Thank you for contacting the Ad Manager API support team. I'm Ankam.

I have checked the details and based on our documentation here are my inputs.

1. Note that Ad Manager supports only two types of Authentication, they are Web application flow and Service account flow. We don't have the Refresh token flow and to determine if your app is using OOB flow with the help of redirect_uri, you can check on the Google cloud platform, here you can also check about the Application type.
2. To know about the accessibility entities on your Service account flow, we require below details.

• SOAP logs(logging must be enabled)
• Network code
• getCurrentUser()

Regards,

Ankam Ad Manager API Team

ref:_00D1U1174p._5004Q2cFsw5:ref

[Mark Sheedy]

Thanks Ankam,

 

When creating the AdManagerUser in a test application

ie. AdManagerUser user = new AdManagerUser();

where the settings are pulled in from my app.config which is configured now for the service account flow, indeed the user.config object has a OAuth2RedirectUri = urn:ietf:wg:oauth:2.0:oob.

 

I’m not sure where the RedirectUri comes from in the config, can you explain that for me? It’s not a setting in app.config and if I read your response correctly, you seem to indicate that our registered application type could have something to do with that RedirectUri being set that way? It doesn’t appear to come from the JWT file?

 

Funnily enough if I clear the RedirectUri (ie. user.Config.OAuth2RedirectUri = "";), then indeed the entities that weren’t working with the service account flow are now returning results! I doubt clearing the RedirectUri is the recommended workaround for this however?

 

If you could also clarify, with the Service Account flow, it appears that the JWT will not expire and that we will pass this onto our clients using our application and have them configure the Service Account in their networks to our Service Account email address for which the JWT was generated?

 

If it helps, our network code is: 38302577

And the service user I’m using there is called “Genera Service Account” (user_id=248113597) which is hooked up to the email I generated the JWT file from.

 

Kind Regards

Mark

 

 

 

 

 

From: Ad Manager API Forum Advisor <admana...@forumsupport.google>
Sent: Monday, 4 July 2022 8:52 PM
To: Mark Sheedy <msh...@atex.com>
Cc: google-doubleclick...@googlegroups.com
Subject: RE: Problems moving from the Refresh Token (Installed app) flow to Service Account flow

 

** EXTERNAL EMAIL **

 

---

[Ad Manager API Forum Advisor]

Hi Sheeds,

Thank you for getting back to us. I am Hosur, a colleague of Ankam and I will be assisting you with this issue.

Based on the Google documents, clarification to user queries.

1. Redirect_uri comes to config only if you are using the OAuth OOB flow but not in the Service account flow.
2. If you are using OOB flow application type then that requires the redirect_uri to determine the Authorization request your app is making via Google OAuth.
3. Yes, redirect_uri will not come from the JWT. JWTs are are composed of three sections: a header, a payload (containing a claim set), and a signature. 
4. Regarding entities that weren’t working with the service account, as we requested earlier we need SOAP logs(logging must be enabled), Network code, getCurrentUser() details for further investigation.
5. For the service account flow you can make authorized API calls using a JWT instead of an access token. JWTs do expire exactly after 3600 seconds. You may refer to this document on how to authorize a service account with JWTs.

And in addition to above points we can say:

However, your queries seems to be more related to the Google cloud. Kindly note, we can only assist you with issues related to Ad Manager API and suggest you reach out for Google cloud support if they have any further queries, as they will be well-equipped to assist the user better.

Regards,

HOSUR Ad Manager API Team

 

ref:_00D1U1174p._5004Q2cFsw5:ref

[Sheeds]

Thanks for the follow up.

By decompiling the Google.Ads.Common package today, we have discovered that the OAuth2RedirectUri is in fact defaulted to oob by the API. See below. When we clear that value then the Service account flow appears to be working for us now.

If the oob flow is being deprecated then perhaps the API shouldn't be defaulting the Uri property this way anymore?

/// <summary>
/// Redirect uri.
/// </summary>
private ConfigSetting<string> oAuth2RedirectUri = new ConfigSetting<string>("OAuth2RedirectUri", "urn:ietf:wg:oauth:2.0:oob");   

[Ad Manager API Forum Advisor]

Hi Mark,

Thanks for getting back out to us. I am Chekurthi, Hosur's colleague and will be assisting you.

I have checked the issue description here and the conversation with the team, I have verified and can confirm that OOB flow is deprecated and it should not be asking the URI property. Please note that our team can only assist with issues related to Ad Manager API and pertaining to the authentication method of Web Application flow and Service Account flow. However, the query here seems to be more related to the Google cloud and I would suggest you reach out for Google cloud support as they are best suited to help you with the same.

Regards,

Chekurthi Ad Manager API Team

ref:_00D1U1174p._5004Q2cFsw5:ref

[Sheeds]

Bit of confusion at our end as to what was being deprecated, but to close this off, essentially we just needed to set the redirect uri to localhost and obtain the authcode from that return url to generate a new refresh token for our desktop application. As per recommendation:

https://developers.google.com/identity/protocols/oauth2/native-app#redirect-uri_loopback

[Ad Manager API Forum Advisor]

Hi Mark,

Thank you for getting back to us.

I can confirm that OOB flow is deprecated and it should not be asking for the URI property. I would recommend that you reach out to the Google Cloud Support  team, because they are well equipped to handle the queries and issues related to the Auth code and redirect uri. Please note that our team can only assist you with the queries and technical concerns related to the Ad Manager API.