1

我正在考虑允许用户使用 Google 登录我的移动应用程序。如果用户已经在他们的设备上登录了 Google，我不希望他们必须重新输入他们的用户名和密码（“原生登录体验”）。用户登录后，他们可以访问我服务器上的私有资源。为此，我使用了 OpenID Connect隐式流。这就是我对流程的理解：

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

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

  3. 我的客户端应用程序将 access_token 和/或 id_token 发送到我的服务器。

  4. 我的服务器验证 access_token和/或验证 id_token

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

  6. 我的服务器创建自己的新安全令牌并将其返回给我的客户端应用程序。

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

问题：

如果我想为用户提供“本机登录体验”，这是用于登录的正确流程吗？

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

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

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

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

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

提前致谢。

4

2 回答 2

0

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

于 2015-01-13T10:29:32.193 回答
0

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

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

如果服务器也直接从客户端处理访问令牌（即不使用服务器流），那么它应该验证它们也属于正确的用户。ID 令牌声明at_hash可用于验证访问令牌确实属于 ID 令牌中标识的同一用户。

另一方面，如果您使用服务器（又名“代码”）流，则服务器会code从客户端获得，并直接在令牌端点交换它，并提供其客户端密码来执行此操作。以这种方式获得的 ID 令牌和访问令牌无需验证，因为它们直接来自 Google。

于 2015-08-25T00:08:35.520 回答