How to validate user credentials for a user account after ClientLogin is sunset?

[Chris]

Hi Guys,

I'm looking at updating our applications to using OAuth2.0 authentication, and it certainly seems that it would be easiest to have all account linked under one master MCC, as described here https://developers.google.com/adwords/api/docs/guides/clientlogin-to-oauth2-single-mcc

However, my concern with this approach, is that I do expect users to occasionally input the id for the wrong account by mistake. The consequences of this could be less than desirable. Currently we use ClientLogin for authentication, and a user is required to input the client id, username and password. If I could still make use of this information, and validate that the login credentials provided are valid for the account id specified, then that would go a long way to alleviating my concerns (it can be easier to see from an email address what account it is associated with, compared to a numeric id).

So, my question is - is there is still a way that I can validate login credentials against an account id?

Or, am I in fact misunderstanding something in relation to OAuth2.0 authentication, since this is the first time I'm really looking into it?

Any thoughts or comments are much appreciated.

Chris

[Josh Radcliff (AdWords API Team)]

Hi Chris,

When your MCC sends out an invitation to an AdWords account (either via the My Client Center UI or a ManagedCustomerService.mutateLink ADD + PENDING call) the user associated with that account will still have to either accept or refuse the invitation. Accepting the link will either be:

1. A manual interaction through the AdWords UI or
   
2. Managed by your application via a ManagedCustomerService.mutateLink SET + ACTIVE call
   

In either case you will be able to detect when the client enters a customer ID for which he does not have access.

1. If the client does not actually own the customer ID then he won't get the invitation at all.  It will either go to the owner of the incorrectly entered account (if it exists) or sending the invitation will fail.
2. In order for your application to accept the link on the user's behalf you will have to prompt the user for permission to manage his AdWords account.  If he entered the wrong account number then the ManagedCustomerService.mutateLink SET + ACTIVE call will fail because the OAuth2 access token will be for an account that does not have access to the incorrectly entered customer ID.

Another possible flow would be that you collect the customer ID and go through the OAuth2 flow at one point, and then at some later point in time go through the MCC invitation process.  If that's your use case then at the point where you collect the OAuth2 token you could issue a simple request such as a CustomerService.get where you specify the clientCustomerId and use the OAuth2 credentials from the user.  If the user entered the wrong customer ID then that request will fail with a permission error.

Cheers,

Josh, AdWords API Team

[Chris]

Hi Josh,

Thanks for your reply! The situation I am concerned with however is where we already have clients linked to our MCC. Let's say that one of the people on our team is setting up a new account in one of applications that uses the AdWords API, and by mistake enters the client id for client X from the MCC rather than for client Y. This is still a valid account, linked to the MCC, but due to a simple mistake is not the client id that we want. If I could also validate this client id against client-specific login credentials then that would be a useful extra step for validating that we infact have the client id that we want to use. A user is less likely to enter incorrect login credentials such as us...@clientX.com for the client Y account.

[Josh Radcliff (AdWords API Team)]

Hi Chris,

Put another way, is your use case as follows?

1. You have MCC M1 and AdWords account A1.
2. A1 is linked to M1.
3. Someone on your team creates AdWords account A2.
4. That same person goes to the MCC UI (or uses your app) to send an invitation to A2 to be linked to M1, but accidentally enters the ID for A1 instead.

In this scenario, if your app then attempts to issue an API request against A2 using OAuth2 credentials from M1, the API request will fail because the link between M1 and A2 was never created or accepted.

I'm not sure if that's actually the use case you described.  If not, could you provide some more details?

Thanks,

Josh, AdWords API Team

[Chris]

Hi Josh,

The use case is as follows:

We have MCC M1 and AdWords accounts A1 and A2

Both A1 and A2 are already linked to M1

We have a web application that has the necessary information to pull data from accounts in M1

Someone logs into our web application and configures a new application account B1, intended to display data for account A1

During the configuration process, the client id for A2 is entered in error

B1 is now pulling and displaying data for A2

It is easier to arrive at this situation when only a client id is required. If a user has to also provide a valid login for the corresponding account, then this kind of error would be less likely, as the mistake should be clearer e.g. in the example above, if we see the credentials for us...@account2.com provided in B1 then this looks like an error has been made

[Josh Radcliff (AdWords API Team)]

Hi Chris,

One way you could deal with the issue you described would be to go through a small OAuth flow for account A1 at this step:

Someone logs into our web application and configures a new application account B1, intended to display data for account A1

If the person entering in the account at that point only has access to A1, then you could:

1. Take the user through the OAuth2 Web Application flow. He would presumably log in at that point as a user who only has access to A1 (you could just request the online access_type instead of the offline access_type for this, since you're going to use the access token immediately).
2. When your website or app gets the authorization code from the OAuth2 flow, exchange it for an access token.
3. Use the access token and the account ID the user entered to perform a basic API request such as CampaignService.get for the account ID he entered. If that fails, then chances are the user entered the wrong account ID.  In the example you gave, you would have an access token for A1 but an account ID for A2, so the request would fail.

Does that sound feasible for your use case?

Thanks,

Josh, AdWords API Team

[Bartosz Ferenc]

Hi Josh,

I have a problem.

1. Customer agrees by Oauth2 on campaign management and application receives ACCESS_TOKEN and refresh_token. Everything is OK.

2. To be able to manage user account I need to know his clientcustomer_id.

3. I want to get them through CustomerService.get using customer refresh_token.

4. API returns permission_denied.

5. If i enter manually $user-> SetClientCustomerId ($client_customer_id) everything works properly.

I would like to receive via CustomerService.get client_customer_id which seems possible - the documentation shows that this method does not require client_customer_id and should be return it, using only refresh_token. Am I right? Why it did not work?

[Josh Radcliff (AdWords API Team)]

Hi,

In step 3, are you clearing the client customer ID? If not, then that attribute may be left over from your previous request or set via the clientCustomerId in your auth.ini file, and the access token probably doesn't have access to that customer ID.

Thanks,

Josh, AdWords API Team

[Bartosz Ferenc]

Hi,

It's works. Another instace /singleton AdwordsUser uses auth.ini in my test code. My test object doesn't use it but had access to this variable. THX

--
--
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog and Google+:
https://googleadsdeveloper.blogspot.com/
https://plus.google.com/+GoogleAdsDevelopers/posts
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
 
You received this message because you are subscribed to the Google
Groups "AdWords API Forum" group.
To post to this group, send email to adwor...@googlegroups.com
To unsubscribe from this group, send email to
adwords-api+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/adwords-api?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "AdWords API Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adwords-api/kSi16kD2eU0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adwords-api+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/adwords-api.

To view this discussion on the web visit https://groups.google.com/d/msgid/adwords-api/2825bdc5-055f-42f1-8f6f-c7e450b287fe%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Pozdrawiam,

Bartosz Ferenc
Prezes Zarządu
bartosz...@iware.pl
tel. kom. + 48 512 296 321

IWARE Sp. z o.o.
Armii Krajowej 6B/4 50-541 Wrocław
tel. + 48 71 336 48 26

NIP: 894-300-73-04, Regon: 021346802
Sąd Rejonowy dla Wrocławia-Fabrycznej we Wrocławiu, VI Wydział Gospodarczy KRS
KRS 0000364948, Kapitał zakładowy 37.500,00 PLN

www.IWARE.pl
 


Niniejszy e-mail oraz wszelkie załączone do niego pliki są poufne i mogą podlegać ochronie prawnej. Jeżeli nie jest Pan/Pani zamierzonym adresatem powyższej wiadomości, nie może jej Pan/Pani ujawniać, kopiować, dystrybuować, ani też w żaden inny sposób udostępniać lub wykorzystywać. O błędnym zaadresowaniu wiadomości prosimy niezwłocznie poinformować nadawcę i usunąć wiadomość.

This e-mail message may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.