RESTful API身份验证设计

Question

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

我正在使用JWT。

我有一个api_users表，该表允许访问API本身。

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

所以这是我感到困惑的地方：

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

如果我采用第三种方法，并且与RESTful（无状态）设计保持一致，是否需要第二个JWT来跟踪user正在请求我的API的内容？

谢谢大家！

Answer 1

您不应有两个表代表两种不同类型的用户（例如API用户/应用程序用户）。一张桌子就足够了。就跟踪哪个用户正在请求您的API而言，您的日志应该足够了，除非您需要在前端存储并提供其他指标，或者您希望限制访问（限制/一次每个用户一个请求）和您的框架无法管理这一点。当您的用户通过您的应用进行身份验证时，他们将获得一个JWT令牌，该令牌可用于进行API调用。

Answer 2

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

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

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

无论哪种情况，您都需要一个用于用户的表和一个用于令牌的表。