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 :) ) ?
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.