如何根据设计的加密密码进行身份验证？答案

【问题标题】：How to authenticate based on devise encrypted password?如何根据设计的加密密码进行身份验证？
【发布时间】：2016-10-28 23:42:23
【问题描述】：

我有两个 Rails 应用程序使用设计进行身份验证：一个网站和一个 API。尽管我是这两个应用程序的所有者，但出于多种原因，我希望将两者完全分离。当用户在网站上注册时，会在 API 端自动创建一个帐户。我遇到的最大问题是让两个应用程序之间的用户表保持同步。我最终在创建/更新 API 用户的网站用户模型上得到了一堆 RESTful API 回调。

第二部分是代表登录网站的用户调用 API。问题是我没有用户的解密密码，所以我可以进行 API 调用。所有 API 调用都使用基本的 HTTP 身份验证。密码被散列到数据库中，无法解密（这是一件好事，谢谢你的设计）。因为我在两个数据库之间保持所有用户列同步，所以我的网站用户 encrypted_password 列与我的 API 用户 encrypted_password 列相同。

那么，我有什么方法可以解决这个问题？我正在考虑修改 API，以便每个常规调用的管理员调用都需要一个管理员用户名和密码以及一个用户 ID（例如，获取该用户的交易）。或者，在两个应用程序之间实现一个共享数据库——但我在用户和其他模型之间有很多关联......索引如何工作？！或者，劫持设计身份验证并将 encrypted_password（来自我的网站）与 encrypted_password（来自我的 API）进行比较——因为它们完全相同；但这打开了蠕虫的安全罐。或者，创建密钥身份验证并为用户生成唯一的 GUID……但这与将解密密码存储在数据库中一样糟糕。我讨厌所有这些解决方案。也许有人有更好的主意？

【问题讨论】：

标签： ruby-on-rails devise restful-architecture

【解决方案1】：

当您在 Devise 中对用户进行身份验证时，它会获取明文密码并将其与胡椒组合并通过 bcrypt 传递。如果加密的密码与数据库中的值匹配，则返回记录。

胡椒是基于你的 Rails 应用程序秘密。因此，除非这两个应用程序具有完全相同的秘密，否则即使您拥有正确的加密密码，身份验证也会失败。请记住，bcrypt 的输入必须相同才能给出相同的结果。这意味着相同的明文、盐、胡椒和延伸数。

您说得对，来回共享密码并不是一个可靠的解决方案。您也是正确的，因为使用 UUID 而不是数字自动递增 id 是解决方案的一部分。

您可以做的是实现自己的身份验证提供程序。 Doorkeeper gem 可以很容易地设置您自己的 OAuth 提供程序（或者，如果可以使用外部服务，您可以使用 Auth0）。

Web 应用程序将使用 Devise + OmniAuth 根据身份验证提供程序对用户进行身份验证，并使用返回的凭据来识别 Web 应用程序中的用户。

对于 API 应用程序，我会使用 Knock 进行 JWT 身份验证。 API 服务器通过 oauth gem 代理到您的身份验证服务器的位置。

但是，此时您应该考虑您的 Web 和 API 应用程序是否真的应该在单独的数据库上运行。在两个数据库之间保持同步写入可能是一项艰巨的任务，您应该问自己在这个阶段是否真的需要它。

【讨论】：

感谢您的所有想法。我最终没有共享数据库，因为在 Rails 世界中，当您考虑迁移时，这会很痛苦。另外，我最终没有使用 JWT，因为我已经阅读了很多文章，当你已经在使用 Devise 时，它们不应该被使用。另外，对我来说，OmniAuth 没有意义，因为我需要所有用户的详细信息（姓名、地址、信用卡等），所以我负担不起使用 Facebook/Twitter。我想生成自己的令牌，但我认为 OAuth 太过分了，所以我最终将 simple_token_authentication 与 Devise 集成。谢谢！
还有一条评论。我设计的认证方式是这样的：当用户登录网站时，我暂时可以访问密码。在那个短暂的时刻，我调用 API 并请求令牌。然后在整个网站会话中使用该令牌。当用户注销或一段时间后，它会过期（在 API 端）。

【解决方案2】：

JWT 可以轻松地在 JWT 中包含诸如用户 ID 之类的信息，而无需依赖外部持久性（例如用户表）。只需确保令牌已正确签名，并且不要在其中存储个人信息（例如电子邮件），因为 JWT 通常不加密而仅签名。

如果有兴趣，我实际上已经写了一篇关于这个的教程。 https://www.moesif.com/blog/technical/restful-apis/Authorization-on-RESTful-APIs/

【讨论】：

谢谢。我对 JWT 了解不多。我最终没有使用它们（见上文）。