1

我必须为移动应用程序开发一个 RESTful API，我对这些部分之间的通信流有些担心。我是移动设备和 OAuth 的 API 开发新手。

共同的项目应该以这种方式工作：

  • 用户只能使用他们的 Google 帐户登录
  • 移动应用程序使用网站 API，所有信息都存储在后端

我在OAuth on REST API for mobile app 上发现了一个类似的问题，我更喜欢它的第一个解决方案，但我对这个解决方案的安全性有一些疑问。

1) 我应该为 API 使用 OAuth2 吗？我不确定将用户的 Google ID 发送到 API 以获取用户数据是否是个好主意。

2) 如何在服务器上检查 Google ID 的正确性和真实性？还是根本不重要？

我正在考虑这种情况，但我不确定这是最好的解决方案：

1) 用户首次使用其 Google 帐户登录移动应用程序。

2) 移动应用程序接收 Google ID 和一些附加信息。

3) 移动应用程序将 Google ID 发送到服务器。

4）服务器使用OAuth2。它为用户创建一个帐户（将 Google ID 保存在数据库中）并向移动应用程序返回一个访问令牌。

5) 移动应用程序将访问令牌存储在本地，并将其用于对服务器的请求。访问令牌过期后，用户必须使用其 Google 帐户再次登录移动应用程序。

我对仅使用 Google ID 生成令牌有些担心。我的意思是，任何人都可以使用某人的 Google ID 来创建令牌。馊主意 ：（

我还应该更好地使用 JWT 作为令牌吗？

谢谢你的帮助！

4

1 回答 1

1
  1. 您应该id_token改为将用户发送到 API

  2. 有几种不同的方法可以在服务器端验证 ID 令牌的完整性：

    a)“手动”——不断下载谷歌的公钥，验证签名，然后是每一个字段，包括那个iss；我在这里看到的主要优势（尽管在我看来很小）是您可以最大限度地减少发送给 Google 的请求数量。

    b) “自动” - 在 Google 的端点上执行 GET 以验证此令牌 https://www.googleapis.com/oauth2/v3/tokeninfo?id_token={0}

    c) 使用Google API 客户端库。

至于工作流程，它大部分是正确的，除了最后一步，您可以在不提示用户许可的情况下刷新访问令牌。顺便说一句，谷歌id_token实际上是一个 JWT。

于 2017-04-13T08:03:26.303 回答