See, if I break the process down into steps:

1. Your application redirects a browser to a Google URL
    1a. the URL includes query parameters that indicate the type of access 
being requested
    1b. importantly, this includes "scope" and "state"

2. You select the Google Account you want to authorize
3. You review the app permissions
4. You hit "Confirm"

5. Your browser compiles a payload to be sent to Google authorization 
server.
    5a. this payload is, in part, used to verify the type of access and 
verify that the request is valid--not a bad actor
    5b. this payload includes two REQUIRED variables, "f.req" and "at"
    5c. this variable "f.req" contains a bunch of data (in a "list") 
specifying everything about the request, to include a token that begins 
with "!ChR"at index 1
    5d. If I were to manually send this same request inside my program, I 
could collect the same response from your validation server--giving tighter 
control over the process

So addressing 5d. I want to be able to manually send the request. This 
means that I need to manually reproduce the variables required by your 
authorization server. 
By my tests, only "f.req" and "at" are required for a valid response. 

So to reproduce "f.req", it's actually pretty simple for the most part. *Where 
the problem arises is the value at index 1. I can not figure out where it 
comes from.*

Here's what I think I know about this value:
1. It is not in any responses from the Google server that come as a result 
of completing steps 1-5. I have searched ALL responses, and this value is 
not in them.
2. Therefore, I believe the value is generated by my browser. 
3. Since this is a Google protocol, Google created the functions that 
output this value, to send to the authorization server. Google put them in 
the webpages files, and it instructs my browser on how to generate the code.

I just want more info on how to do it manually, rather than allowing my 
browser to do it.


On Thursday, November 17, 2022 at 8:14:48 AM UTC-8 Chad Wood wrote:

> Thanks, and you are right that the access token and refresh token is 
> generated by Google side.
>
> About this: "the URL includes query parameters that indicate the type of 
> access being requested"
> This is also correct. Here's what the url would look like:
>
> https:// accounts. google. com/o/oauth2/auth?
>     response_type=code&
>     client_id=
> 995929737391-l3og1l1d44gpf4985e0l7elkk4b26nn.apps.googleusercontent.com&
>     redirect_uri=http%3A%2F%2F127.0.0.1%3A8080&
>     scope=https%3A%2F%2Fwww.googleapis.com
> %2Fauth%2Fadwords&state=efcck0648b44377bedj20e97d2eca2745ba5979cf2cfa4sk30d2da6365sk2681&
>     access_type=offline&prompt=consent&
>     include_granted_scopes=true
>
> See the parameters it's talking about here are:  response_type, client_id, 
> redirect_uri, scope,  access_type, and  include_granted_scopes 
>
> What I'm talking about goes deeper into the process than any documentation 
> covers though. See, on my side of things, the browser actually generates a 
> "code" that it eventually sends to your server once I hit the "Confirm" 
> button.
> That "code" is what I showed in the picture from my last message (section 
> three). This code is basically verified by your server, as a type of 
> security feature I assume. As it would likely be very difficult for a bad 
> actor to get all the input data needed to reproduce that "code".
>
> But I am not a bad actor. I basically want to reproduce that "code" inside 
> my own personal program--not inside a browser. This way, I can send 
> authorization requests to your server manually.
> I have tested ripping the payload from the browser and sending it in my 
> program. In this case, your server WILL respond with the redirect URL 
> containing the refresh token. This is confirmed working.
> The only issue is that it requires me to manually rip the payload, which 
> defeats the entire purpose. 
>
> Now, I can reproduce most of the payload. The only part I can not 
> reproduce is the "code" I am referring to. It is at index 1 of the "f.req" 
> variable inside the payload.
> Somehow, my browser is generating this "code" using the page's JavaScript 
> instruction to do so. Then it places the "code" inside an array labeled 
> "f.req" and sends that to your server. Your server validates it and 
> responds with the refresh token stuff.
>
> I only want to understand how that "code" is created. What is my browser 
> doing? Is it hashing cookie variables? If so, what type of hash and which 
> variables?
> Again, it is the token that always begins with "!ChR" at index 1 of 
> variable "f.req" in the payload that gets sent to your authorization server 
> for the refresh token.
>
> Can I have more insight on how my browser generates this code/token? I 
> tried reviewing the JavaScript in the page, but it's a mile long and none 
> of the function names appear meaningful--so it is very difficult to figure 
> out,
> On Wednesday, November 16, 2022 at 5:41:44 PM UTC-8 adsapi wrote:
>
>> Hi Chadwood,
>>
>> Thank you for getting back to us.
>>
>> Thank you for providing us your main goal. Please note that Google the 
>> access token and refresh token is generated by Google side. Based on this 
>> article 
>> <https://developers.google.com/identity/protocols/oauth2#scenarios> "The 
>> authorization sequence begins when your application redirects a browser to 
>> a Google URL; the URL includes query parameters that indicate the type of 
>> access being requested. Google handles the user authentication, session 
>> selection, and user consent. The result is an authorization code, which the 
>> application can exchange for an access token and a refresh token.
>>
>> You may check this article 
>> <https://developers.google.com/identity/protocols/oauth2#5.-refresh-the-access-token,-if-necessary.>
>>  for 
>> more information.
>>
>>
>> Kind regards, 
>> [image: Google Logo] 
>> Sherwin Vincent 
>> Google Ads API Team 
>>   
>>
>> ref:_00D1U1174p._5004Q2gPExm:ref
>>
>

-- 
-- 
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog:
https://googleadsdeveloper.blogspot.com/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

You received this message because you are subscribed to the Google
Groups "AdWords API and Google Ads API Forum" group.
To post to this group, send email to adwords-api@googlegroups.com
To unsubscribe from this group, send email to
adwords-api+unsubscr...@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 the Google Groups 
"Google Ads API and AdWords API Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to adwords-api+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/adwords-api/4f6ff3a9-38eb-4fcb-bb1e-b8b7e420595dn%40googlegroups.com.
  • Tr... Chad Wood
    • ... Chad Wood
      • ... Chad Wood
        • ... Chad Wood
          • ... Chad Wood
            • ... Chad Wood
              • ... Chad Wood
                • ... Chad Wood
              • ... Chad Wood
              • ... Chad Wood
              • ... Chad Wood
                • ... 'Google Ads API Forum Advisor' via Google Ads API and AdWords API Forum
    • ... Chad Wood

Reply via email to