Oauth 2.0 在移动客户端和服务器之间处理OpenID Connect id_令牌和access_令牌的安全风险（谷歌登录）

我正在考虑允许用户使用谷歌登录我的移动应用程序。如果用户已经在他们的设备上登录到Google，我不希望他们必须重新输入用户名和密码（“本地登录体验”）。一旦用户登录，他们就可以访问我的服务器上的私有资源。为了实现这一点，我使用OpenID连接。以下是我对流程的理解：

1） 用户正在使用我的移动客户端应用程序（ios或android），并选择登录谷歌

2） 我的客户端应用程序（使用谷歌ios或android SDK）获得和（假设用户已安装Google+应用程序，已登录并已授予我的应用程序权限）

3） 我的客户端应用程序将访问令牌和/或id令牌发送到我的服务器

4） 我的服务器和/或

5） 使用任一令牌，我的服务器将google用户映射到我自己数据库中的一个用户

5） 我的服务器创建自己的新安全令牌并将其返回到我的客户端应用程序

6） 我的客户端应用程序在对我的服务器的后续请求中使用新的安全令牌来访问私有资源

问题：

如果我想给用户“本机登录体验”，这是登录时使用的正确流程吗

假设我遵循谷歌的所有指导原则（例如使用SSL、在头数据或POST数据中发送令牌、正确验证令牌）

从客户端发送访问令牌时存在哪些漏洞

从客户端发送id_令牌时存在哪些漏洞

此流程还存在哪些其他安全风险

这似乎是一个非常常见的用例。这就是大多数应用程序在谷歌上实现“本地身份验证”所做的吗？应用程序的例子将不胜感激

---

提前谢谢

可能不是一个完整的答案，但我对此有一个想法：我认为发送访问令牌存在潜在风险，因为服务器可以存储它（增加盗窃风险）和/或在没有SSL的情况下将其发送到其他地方，然后暴露访问令牌，不是吗？由于谷歌指南（如SSL使用）不是强制性的（不可能，也没有办法检查），因此该指南之外的所有潜在使用都是危险的。这不是一个你可以避免的风险，但无论如何，这是一个风险。我也没有看到关于访问令牌的服务器存储的指导原则。

任何时候客户端将ID令牌传递给服务器（包括隐式流中的所有ID令牌），服务器都必须完全验证它

Google有一些关于如何验证ID令牌的文档，请参见：

如果服务器也直接从客户端处理访问令牌（即不使用服务器流），那么它应该验证它们是否也属于正确的用户。可以使用位于\u hash的ID令牌声明

---

另一方面，如果您使用服务器（也称为“代码”）流，则服务器将从客户端获得

代码

，并直接在令牌端点处进行交换，从而显示其客户端密码。通过这种方式获得的ID令牌和访问令牌不需要验证，因为它们直接来自谷歌。

您好，谢谢您的回复。如果不使用SSL，服务器将不会存储访问令牌或将其发送到任何地方。我更关注的是服务器在未首先启动流的情况下接受access\u令牌或id\u令牌的潜在问题，例如，它是否容易受到重播攻击？客户端是否应该首先请求在我的服务器上生成的nonce，然后使用id_令牌将其发送到我的服务器进行验证