Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

/oauth2/v4/token unreliable

drzraf
New Member

`/oauth2/v4/token`  is a core component of many organizations' authentication.  Sadly its reliability can be questioned.

1. It's not explicitly referenced on https://status.cloud.google.com/regional/multiregions : No way to know about maintenance, anticipated or not

2. Timeouts. One of my systems has a 5-seconds timeout tolerance but `/oauth2/v4/token` have been seen to take up to 50 seconds to reply:

$ time curl -6 https://www.googleapis.com/oauth2/v4/token -d code=4/... -d client_id=.......apps.googleusercontent.com -d client_secret=.... -d redirect_uri="https://...." -d grant_type=authorization_code -d "scope=email profile openid" -d access_type=offline -d prompt=consent
{
"error": "invalid_grant",
"error_description": "Bad Request"
}
real 0m50,612s
user 0m0,031s
sys 0m0,018s

 3. Network inconsistency

The worst part is the impossibility to know whether this endpoint will reply when called from a given datacenter/IP-address/v4/v6.

While "invalid credentials" responses are quick ; as soon a valid client-id/secret is passed, the request seems routed through an internal layer whose response depends heavily upon source IP address. The exact same request can takes 8ms from Germany, 50 seconds from UK and even receive a TCP-error when issued from Canada!

It's been known that this endpoint is banning IPv6 block too lightly (even a whole /56s I belonged to which casually happened to be allocated to a competing hosting provider ...)

The fact that a valid response-time vary from 8ms to 50s but an invalid one returns consistently/immediately is another hint that this endpoint is doing something wrong regarding client network/location behind the scene.
(Small reminder that deteriorating performances when detecting a competitor is illegal under most European jurisdictions and UE-jurisdiction itself)

 

I won't ditch one particular VPS provider just because GCP isn't compliant with it, I won't stop using IPv6 either and I can't accept unreliable or minute-level timeout for such a strategic API endpoint.

I just want it to respond quickly and consistently, whatever the location/IP version/network block my server are in.

Is that too much? Could this finally be resolved?

 

#api #oauth #openid #network #connectivity #ipv6 #competition

 

1 0 222
0 REPLIES 0
Top Labels in this Space
Top Solution Authors