Java 谷歌认证服务迁移-如何确保该过程成功完成？

谷歌已经宣布，他们正在迁移他们的认证服务，以整合API的工作方式，并使其“更简单”。我们希望确保我们的应用程序能够正常工作，但不确定我们采取的措施是否足够

我们有一个Java服务器应用程序，它使用

GoogleOAuth客户端

及其

AuthorizationCodeFlow

来授权用户。我们有一个在Google开发者控制台中创建的web应用程序的客户端ID。我们也在那里定义了一个重定向URI。 我们使用开发者控制台中的密钥和密码来创建GoogleAuthorizationCodeFlow。当从该对象创建授权URL时，我们提供在开发人员控制台中定义的重定向URL

我们已将作用域“”更改为“电子邮件”（我们现在使用它来调用

plus.people（）.get（“me”）

，而不是

oauth2.userinfo（）.v2（）.me（）.get（）

）。最后，我们在创建GoogleAuthorizationCodeFlow时提供的作用域是“email”、“openid”和“”

我们使用获得的令牌来操纵用户的日历和查找用户的电子邮件

我们觉得关于整个授权工作原理和迁移指南的文档过于分散，很难理解整个过程背后的基本原理

---

在开发我们的应用程序时，我们尽了最大的努力来充分理解OAuth 2.0以及它如何与Google API一起工作。我们阅读了文档，参加了OAuth 2.0研讨会，并遵循了Google的指南。我们认为我们对幕后发生的事情有相当好的了解。然而，有了这个迁移指南，我们就产生了困惑。我们真的在使用OAuth2.0登录吗？我们是否使用OpenID2.0（因为我们使用OPIND和电子邮件作用域s来接收用户的电子邮件以及令牌）？我们使用的是OpenID+OAuth混合吗？所有这些选项都有关于如何迁移的单独子指南，这无助于避免混淆。因此，我们的问题是：迁移过程结束后，此设置会起作用吗？我们误解了什么吗？

在切换日期之后，我们在oauth上没有遇到任何问题，这意味着我们所采取的步骤（在我们的问题中列举的步骤）已经足够了，服务工作正常。

为什么不设置一个测试环境并测试它呢？你是什么意思，我们如何建立一个测试环境，测试Google域名在迁移完成后的表现？我们很乐意这样做。你能提供一个链接到“谷歌已经宣布……”吗？如果是你的意思，这不是谷歌在某处迁移，但你的应用程序必须迁移。如果你阅读链接的网站，你会看到他们不赞成并禁用我们设计应用程序时使用的授权方式。如果你遵循指导原则，并且确定你没有使用不赞成的方法，你的问题听起来会是什么样的？行吗？如果你不能测试它，就不会有及时的答案。