Cannot authenticate anymore with new Google OAuth 2.0 token endpoint (v3)

Question

I have a bunch of tests using Google Accounts as Identity Provider with OAuth 2.0 that are failing since 5th of december with an error around the expires_in field of the access token response that is no more a JSON Number but a String (I'm using grant_type=authorisation_code, but that shouldn't make any difference):

{
   "access_token": "ya29.1gD56tBWtHW3K7oZ0FINTnsqa4VYiE2YGZeQXgJ4ID79E-mZxNWoyYi7pKrs_Vyxj8FZbuxh_RGTJw",
   "token_type": "Bearer",
   "expires_in": "3600",
   "refresh_token": "1/dGjGYC7sDFaBwpdUVpkJP2mYFYTU8HAh7T6szsKGYTs"
}

I'm not using any OAuth 2.0 Client library, so I directly deal with the JSON content.

I did noticed that the both the OpenIDConnect and OAuth2WebServer developers web pages have been updated the 5th of December.

As there is no history available, I could not see clearly what have been changed, but I noticed that the token endpoint URL (returned by the OpenID Connect Discovery Endpoint) has now a v3/ path segment.

After some googling, I found the old token endpoint (https://accounts.google.com/o/oauth2/token), and it appears that this endpoint returns me an access token response with expires_in expressed as a JSON Number.

After reading the OAuth 2.0 specification, it appears to me me that expires_in should be expressed as a Number, not a String, and so the new response format is not compliant in regards to the standard.

See RFC 6749, Section 4.1.4 and Appendix #14 for the expires_in syntax (only digits).

Are there any plans to fix this on Google side ? Or do we (any OAuth 2.0 client in fact) have to deal with an additional special case (let's call that flexibility :) ) ?

Answer 1

Thanks for letting us know. We are looking into this and will try to fix this soon.

Answer 2

Thanks for bringing this to our attention.

I've pushed a change that updates this endpoint to return the expires_in field as a JSON Number rather than a String as per the spec from RFC 6749.

Answer 3

For one thing, the "expires_in" is a recommended field, not a required one; so your implementation should be prepared to deal with omitted or erroneously parsing values.

But of course Google should follow the spec if they intended to provide this functionality. I've contacted Googler's on OpenID Connect working interop list for that, hoping they'll respond accordingly.