RESTful API 认证设计

RESTful API authentication design

有点概念性的问题：我正在设计一个私有 RESTful API，它将被 iOS 和 Android 应用程序使用。

我正在使用 JWT。

我有一个 api_users table 允许访问 API 本身。

我还有一个 users table 供使用应用程序的个人用户登录（即个人的电子邮件和密码）。

这就是我感到困惑的地方：

  1. 我应该放弃 api_users table 并为 users 使用单一身份验证端点，还是
  2. 登录过程是否需要 api_users' 和 users' 返回有效 JWT 的凭据；或
  3. 我是否应该有两个单独的身份验证端点（一个用于 api_users，另一个用于常规 users）。

如果我采用第三条路线，与 RESTful（无状态）设计保持一致，我是否需要第二个 JWT 来跟踪 user 请求我的 API 的内容？

谢谢大家！

您不应有两个 table 代表两种不同类型的用户（例如 API 用户/应用用户）。一个table就够了。在跟踪用户请求您的 API 方面，您的日志应该足够了，除非您需要在前端存储和显示其他指标，或者您希望限制访问（节流/每个用户一次请求时间）和你的框架不管理这个。当您的用户使用您的应用进行身份验证时，他们现在将获得一个 JWT 令牌，该令牌可用于进行 API 调用。

A RESTful API 不应该有一个需要维护状态的登录过程。您将通过为每个请求提供有效的 JWT 数据包来进行身份验证，并且为了创建数据包，您需要一个令牌和某种唯一的帐户标识符。您将不需要任何密码来创建 JWT 数据包。

关于获得令牌，您有两种选择：

  • 您可以创建一个需要主帐户 user/pass（而不是 JWT）的端点，然后分发一个新令牌。然后在后续基于 JWT 的请求中使用该令牌。这是一个更简单的设计，但这种方法有两个主要缺点：
    • 您无法控制令牌，因此您的所有日志记录和限制都必须在用户级别完成。
    • 使用 API 需要您知道主帐户的密码。
  • 您可以设计站点的前端，以允许登录用户使用 create/manage 任意数量的 API 令牌。这有许多优点：
    • 使用 API 不需要知道主帐户的密码。这允许用户在不放弃对其帐户的完全访问权限的情况下将令牌分发给第三方（如链接的应用程序）。
    • 每个令牌都可以严格控制。例如，您可以单独 log/throttle 它们，并且可以在不影响其他任何人的情况下撤销它们。

无论哪种情况，您都需要一个 table 用于用户，另一个 table 用于令牌。