"Error processing OAuth 2 request" - geographical distance between user/web server race condition

Andrew Armstrong

unread,

Aug 7, 2012, 8:36:51 PM8/7/12

to oauth...@googlegroups.com

Hi,

I've identified a problem with Google Authentication and specifically obtaining access tokens for Google Drive.

The geographical distance between the Google user performing authentication, and the 3rd party web server asking for authentication (me), seems to matter.

I can consistently receive this error message:

---

<HEAD><TITLE>Error processing OAuth 2 request</TITLE></HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"><H1>Error processing OAuth 2 request</H1><H2>Error 500</H2></BODY></HTML>
---

When requesting an access token for a customer that has moments ago clicked "Allow access" to my request on the Google auth page.

The scenario under which this happens appears to be:

1) I am located in Australia. When I visit the "Allow access" page, I am being served from an Australian based Google web server when viewing the "Allow access" page

2) My web server is located in West Europe. When the web server receives the redirect response after I click "Allow access", and it there-fore attempts to request an access token from its end, it receives the above "Error processing OAuth 2 request" error page, because it is accessing a West Europe Google server.

3) Adding a 'hosts' directive to map the West Europe server's accounts.google.com etc address to the same Australian web server as mine, and I don't get this issue

4) Simply waiting up to 80 seconds (for what appears to be a "sync" between Google geographical regions) when first seeing the "Error processing ..." error message (or after clicking "Allow access"), the access token request issued by my West Europe web server works and returns the requested access token.

I can basically keep re-trying the request until it works, usually up to a 1min 30 sec delay until it works.

5) Users who happen to be in Europe (or closer geographically to my West Europe web server?) may not encounter this problem

6) The same code base works without issue locally, as I personally get an Australian "Allow access" web server, and since my local dev environment also is in Australia, my Australian web server (on the computer I am visiting the "Allow access" page from) immediately succeeds at obtaining the access token

Attached is an example transcript of a session that fails (DotNetOpenId auth logs in C#), notice the timestamps.

Is this a known issue Google-ers?

Kind Regards,

Andrew

OAuth2 Failure Example.txt

Alexander Sedov

unread,

Aug 7, 2012, 9:46:29 PM8/7/12

to oauth...@googlegroups.com

Google ignores this issue. Maybe you have more luck to solve this. My temporary solution, if I receive HTTP 500 error, I use another server in a different geographic region.

среда, 8 августа 2012 г., 7:36:51 UTC+7 пользователь Andrew Armstrong написал:

Breno de Medeiros

unread,

Aug 8, 2012, 1:38:37 PM8/8/12

to oauth...@googlegroups.com

Google codes were designed to be fetched reliably across geographic
regions. We are trying to investigate this issue (we had several
independent reports so we are taking it seriously) but have difficulty
reproducing it.

Question: Are you receiving codes that look like 'blob.blob', where
the first blob is about 30 characters or so, but the total code is
probably 60 characters or more? Are you sending the entire code back?
Could it be that your code is truncating the code and returning only
the part before the '.'?

Breno (Google).

> --
> You received this message because you are subscribed to the Google Groups
> "oauth2-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/oauth2-dev/-/T5rGB8nFY5oJ.
>
> To post to this group, send email to oauth...@googlegroups.com.
> To unsubscribe from this group, send email to
> oauth2-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/oauth2-dev?hl=en.

--
--Breno

Andrew Armstrong

unread,

Aug 8, 2012, 8:18:14 PM8/8/12

to oauth...@googlegroups.com

Hi Breno,

Thanks for the reply. I'm happy to help you investigate this issue.

Please contact me at and...@121cast.com and we can discuss private details if you like.

I see our library (which I did not write) receiving an id_token in format: <20 characters>.<372 characters>.<171 characters>

The access_token is <4 characters>.<54 characters>

The refresh token is 1/<43 characters>

As mentioned before, the same request that initially fails with a 500 error will succeed (the exact same one, same credentials being sent, etc) after about 70 seconds of waiting.

Regards,

Andrew

Breno de Medeiros

unread,

Aug 8, 2012, 9:36:47 PM8/8/12

to oauth...@googlegroups.com

Thanks. I think we have identified the issue. I will post back when we have a solution live.

To view this discussion on the web visit https://groups.google.com/d/msg/oauth2-dev/-/hiPE9rjLVHwJ.

Ja Ch

unread,

Sep 10, 2012, 9:02:26 AM9/10/12

to oauth...@googlegroups.com

Any update? We really need this fixed.

The closest azure data center's in singapore. Deploying an app there that targets australia using OAuth runs into this problem.

Breno de Medeiros

unread,

Sep 10, 2012, 11:16:39 AM9/10/12

to oauth...@googlegroups.com

We have identified the issue. It was difficult to diagnose because we don't have the error traces. We believe now that the errors are being generated client-side due to the client reaching a configured timeout threshold (5s is a popular default for clients) and then hanging up on the connection to the server before the Google server is able to respond.

We have started work to address the Asia-Europe cross-continental excessive delay but it is a complex fix that may take a few weeks to deploy in a confident manner. In the interim if you are able to change the settings on your HTTP client to wait up to 10s before reporting server error you should see the failure rates fall to acceptable levels.

--

Aleks King

unread,

Feb 13, 2013, 11:30:50 AM2/13/13

to oauth...@googlegroups.com

The problem still exists, isn't it ?

Any update ?

Andrew Armstrong

unread,

Feb 14, 2013, 4:41:50 PM2/14/13

to oauth...@googlegroups.com

I've been scouring my commit logs for how (if) I managed to fix this, but we seem to be having no issues right now.

The underlying fix I think from your end Aleks as a work-around will be to just try again. From memory the Google servers will throw that initial HTTP 500 error, but if you try again anywhere up to 30-60 seconds later, it will work.

So you may want to have your authentication code simply retry up to 60 seconds with the same auth token it received if it hits a 500 error, and it should eventually succeed.

Regards,

Andrew

Aleks King

unread,

Feb 16, 2013, 12:12:55 PM2/16/13

to oauth...@googlegroups.com

Thank you for reply Andrew.

It shows 500 error sometimes even after an hour from the first attempt. Nothing helps except logout. No error after the logout for some time, then error again.

In our case the problem started when 'oauth2_approval_prompt' was changed from 'force' to 'auto'. It's more convenient for our users, but this bug makes a lot of hassle.

Hope Google will resolve it soon and just want to be sure, that this is not the problem on our side.

Reply all

Reply to author

Forward