3

我有一个 LAMP-stack webapp，它公开了一个 REST API。目标是拥有 3 层 - 数据库、服务 (REST) 和多个前端客户端（网站、Android、iPhone）。目前，这些层都在同一个盒子上。网站使用 API 调用服务逻辑进行 CRUD 操作，移动客户端尚未构建。

我正在使用 PHP bcrypt 实现来存储用户凭据。这在设计上很慢/ CPU 密集型。每个 API 调用都需要一个用户名/密码对以及 API 参数。这将阻碍大规模扩展，因为每次 API 调用都会计算哈希值。

所以，我一直在寻找替代方案。OAuth 2.0 使用不昂贵的可撤销令牌，但我读过的文章似乎表明该协议的主要用例是让第三方访问我的 API。这不太适合我的模型，例如，移动客户端归我所有。

  1. OAuth 是否仅适用于第三方，或者公司通常会将其移动客户端添加为自己的 API 的 OAuth 消费者？

  2. 是否可以将共享密钥与我发布到应用市场的 Android/iPhone 应用捆绑在一起，以便它们能够立即与 API 关联？

4

1 回答 1

3

oAuth v2 ( http://oauth.net/2/ ) 有许多身份验证模式（总共 6 个），尽管最终用户授权 3rd 方应用程序的“3 条腿”场景是最明显的，但它绝对是一个好方法，甚至如果您拥有这些应用程序。

您可以使用两条腿的流程，例如受信任的凭证流程https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-25#section-4.3。基本上，在此您信任客户端代码（您编写它）来接收和查看用户的用户名和密码并将其发送到您的 API。完成此操作后，oAuth 令牌将照常出现，密码无需再次通过连接。

关于共享密钥的第二个问题 - 如果您的应用程序始终需要用户登录，那么您可能能够避免将共享密钥放入应用程序，因为您的身份验证依赖于用户凭据（在这种情况下，只需在应用程序中放置一个 ID，以便您知道它是哪个版本）。如果应用程序在某些模式下无需用户登录即可运行，那么您可能别无选择，只能至少在初始化步骤中嵌入某种秘密。

于 2012-04-25T06:38:42.373 回答