安全风险处理移动客户端和服务器之间的OpenID连接id_token和access_token (Google登录)

Question

我正在寻找允许用户登录到我的移动应用程序使用谷歌。如果用户已经在他们的设备上登录到谷歌，我不希望他们不得不重新输入他们的用户名和密码(‘本地登录体验’)。一旦用户登录，他们就可以访问我服务器上的私有资源。为了实现这一点，我使用了OpenID连接隐式流。我就是这样理解流程的：

1. 一个用户正在使用我的移动客户端应用程序(ios或android)，并选择登录谷歌。
2. 我的客户端应用程序(使用谷歌ios或android )获得了一个令牌和令牌 (假设用户已经安装了Google+应用程序，并且已经登录并允许我的应用程序)。
3. 我的客户端应用程序将access_token和/或id_token发送到我的服务器。
4. 我的服务器令牌和/或令牌
5. 使用任一标记，我的服务器将google用户映射到我自己数据库中的用户。
6. 我的服务器创建了自己的新安全令牌，并将其返回给我的客户端应用程序。
7. 我的客户端应用程序在随后对服务器的请求中使用新的安全令牌来访问私有资源。

问题：

如果我想给用户一个“本地登录体验”，这是正确的登录流程吗？

假设我遵循所有googles准则(例如使用SSL，在头数据或POST数据中发送令牌，正确验证令牌).

从客户端发送access_token存在哪些漏洞？

从客户端发送id_token存在哪些漏洞？

该流程还有哪些其他安全风险？

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

提前谢谢。

Answer 1

也许不是一个完整的答案，但我对此有一个想法:我认为发送access_token存在潜在的风险，因为服务器可以存储它(增加盗窃风险)和/或将其发送到其他地方，而不需要SSL然后公开access_token，不是吗？由于Google指南(如SSL使用)不是强制性的(不能，也没有办法检查它)，指南中的每一个潜在用途都是危险的。不是你能避免的风险，但无论如何都是风险。我也没有看到关于access_token服务器存储的指导方针。

Answer 2

每当客户端将ID令牌传递给服务器(这包括来自隐式流的所有ID令牌)时，服务器必须完全验证它。

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

• 网站
• iOS
• 安卓

如果服务器还直接从客户端处理访问令牌(即不使用服务器流)，则应该验证它们是否属于正确的用户。ID令牌声明at_hash可以用于验证访问令牌是否属于ID令牌中标识的同一个用户。。

另一方面，如果您使用服务器(又名“代码”)流，那么服务器将从客户端获得code，并在令牌端点直接交换它，从而显示其客户端秘密。以这种方式获得的ID令牌和访问令牌不需要验证，因为它们直接来自Google。