我使用Google帐户作为身份提供商与OAuth 2.0进行了一系列测试，这些测试自12月5日以来失败，并且访问令牌响应的expires_in字段周围出现错误，不再是{{1}但是JSON Number（我正在使用String，但这应该没有任何区别）：
grant_type=authorisation_code我没有使用任何OAuth 2.0客户端库，所以我直接处理JSON内容。
我注意到OpenIDConnect和OAuth2WebServer开发人员网页都已于12月5日更新。
由于没有可用的历史记录，我无法清楚地看到已更改的内容，但我注意到令牌端点URL（由OpenID Connect Discovery端点返回）现在具有{
"access_token": "ya29.1gD56tBWtHW3K7oZ0FINTnsqa4VYiE2YGZeQXgJ4ID79E-mZxNWoyYi7pKrs_Vyxj8FZbuxh_RGTJw",
"token_type": "Bearer",
"expires_in": "3600",
"refresh_token": "1/dGjGYC7sDFaBwpdUVpkJP2mYFYTU8HAh7T6szsKGYTs"
}
路径段。
在一些谷歌搜索后，我找到了旧的令牌端点（https://accounts.google.com/o/oauth2/token），看来这个端点返回一个访问令牌响应，v3/表示为JSON号。
在阅读OAuth 2.0规范之后，在我看来expires_in应该表示为数字，而不是字符串，因此新的响应格式与标准不一致。
有关expires_in语法（仅限数字），请参阅RFC 6749，第4.1.4节和附录＃14。
有没有计划在谷歌方面解决这个问题？或者我们（事实上任何OAuth 2.0客户端）必须处理一个额外的特殊情况（让我们称之为灵活性:)）？
答案 0 :(得分：3)
感谢您告诉我们。我们正在研究这个问题，并会尽快解决这个问题。
答案 1 :(得分：2)
感谢您引起我们的注意。
我已推送更新此更新此端点，以根据RFC 6749的规范将expires_in字段作为JSON编号而不是字符串返回。
答案 2 :(得分：0)
首先，＆＃34; expires_in＆＃34;是一个推荐的领域，而不是必需的领域;所以你的实现应该准备好处理省略或错误解析的值。
但是，如果他们打算提供此功能，Google当然应该遵循规范。我已经在OpenID Connect工作互操作列表上联系了Googler，希望他们能够做出相应的回应。