REST API身份验证

Question

我正在构建一个将托管在服务器上的应用程序。我想为应用程序构建一个API，以便于与任何平台（Web App，Mobile App）进行交互。我不理解的是，在使用REST API时，我们如何对用户进行身份验证。

例如，当用户登录然后想要创建论坛主题时。我怎么知道用户已经登录？

Answer 1

例如当用户登录时。现在假设用户想要创建论坛主题，我怎么知道用户已经登录？

考虑一下 - 必须有一些握手告诉你的“创建论坛”API，这个当前请求来自经过身份验证的用户。由于REST API通常是无状态的，因此必须将状态保持在某处。使用REST API的客户端负责维护该状态。通常，它是以某种令牌的形式从用户登录时传递的。如果令牌是好的，那么您的请求是好的。

检查Amazon AWS如何进行身份验证。这是从一个API到另一个API“推卸责任”的完美示例。

*我想在我之前的回答中添加一些实际的回答。尝试Apache Shiro（或任何身份验证/授权库）。最重要的是，尽量避免自定义编码。一旦您集成了您喜欢的库（我使用Apache Shiro，顺便说一句），您就可以执行以下操作：

1. 创建一个登录/注销API，例如：/api/v1/login和api/v1/logout
2. 在这些登录和注销API中，使用您的身份执行身份验证 用户商店
3. 结果是一个令牌（通常是JSESSIONID），会被发送回客户端（网络，移动，无论如何）
4. 从此时起，您的客户进行所有后续通话 将包含此令牌
5. 假设您下次调用名为/api/v1/findUser
的API
6. 这个API代码要做的第一件事就是检查令牌（“是 此用户已通过身份验证？“）
7. 如果答案返回为NO，则抛出HTTP 401状态 回到客户端。让他们来处理。
8. 如果答案为是，则继续返回所请求的用户

这就是全部。希望这可以帮助。

Answer 2

您可以使用HTTP基本身份验证或摘要式身份验证。您可以在其顶部使用SSL安全地对用户进行身份验证，但是，它会稍微降低API的速度。

• 基本身份验证 - 对用户名和密码使用Base64编码
• 摘要式身份验证 - 在通过网络发送用户名和密码之前对其进行哈希处理。

OAuth 是最好的。 oAuth给出的优点是可撤销或可过期的令牌。请参阅以下有关如何实施： 来自评论的工作链接：https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf

Answer 3

1. 使用 HTTP Basic Auth 对客户端进行身份验证，但仅将用户名/密码视为临时会话令牌。
   
   会话令牌只是附加到每个 HTTP请求的标头，例如：Authorization: Basic Ym9ic2Vzc2lvbjE6czNjcmV0
   
   上面的字符串Ym9ic2Vzc2lvbjE6czNjcmV0就是字符串＆＃34; bobsession1：s3cret＆＃34; （用户名/密码），用Base64编码。

2. 要获取上面的临时会话令牌，请提供API函数（例如：http://mycompany.com/apiv1/login），该函数将master-username和master-password作为输入，创建临时HTTP Basic Auth用户名/密码服务器端，并返回令牌（例如：Ym9ic2Vzc2lvbjE6czNjcmV0）。此用户名/密码应该是临时的，它应该在20分钟后过期。

3. 为了增加安全性，请确保您的REST服务通过HTTPS提供，以便信息不会以明文形式传输

如果您使用的是Java，Spring Security库可以为实现上述方法提供良好的支持

Answer 4

我认为最好的方法是使用OAuth2。谷歌，你会发现很多有用的帖子来帮助你进行设置。

从Web应用程序或移动应用程序开发API的客户端应用程序将变得更加容易。

希望它对你有所帮助。

Answer 5

这是一个指导方法。

您的身份验证服务发出一个 JWT 令牌，该令牌使用一个秘密在您的 API 服务中也可用进行签名。他们也需要在那里的原因是你需要验证收到的令牌以确保你创建了它们。 JWT 的好处在于，如果不同的用户具有不同的访问控制级别，它们的负载可以声明用户有权访问的内容。

该架构使身份验证无状态：无需在数据库中存储任何令牌，除非您想处理令牌黑名单（想想禁止用户）。如果您需要扩展，无状态是至关重要的。这也使您的 API 服务无需调用身份验证服务器，因为身份验证和授权所需的信息都在已发布的令牌中。

流程（无刷新令牌）：

1. 用户通过身份验证服务器进行身份验证（例如：POST /auth/login）并接收由身份验证服务器生成和签名的 JWT 令牌。
2. 用户使用该令牌与您的 API 对话并假设用户已获得授权）、获取并发布必要的资源。

这里有几个问题。也就是说，错误使用的身份验证令牌为恶意用户提供了无限制的访问权限，以假装他们是受影响的用户并无限期地调用您的 API。为了解决这个问题，令牌有一个到期日，每当到期时，客户都被迫请求新的令牌。该到期时间是令牌有效载荷的一部分。但是如果令牌是短暂的，我们是否要求用户每次都使用他们的用户名和密码进行身份验证？不。我们不想每 30 分钟到一个小时询问用户密码，并且我们不想在客户端的任何地方保留该密码。为了解决这个问题，我们引入了刷新令牌的概念。它们是寿命更长的令牌，用于一个目的：充当用户的密码，对它们进行身份验证以获取新令牌。缺点是使用这种架构时，您的身份验证服务器需要将这些刷新令牌保存在数据库中。

新流程（带有刷新令牌）：

1. 用户通过身份验证服务器进行身份验证（例如：POST /auth/login）并接收由身份验证服务器生成和签名的 JWT 令牌，以及他们安全存储的长期（例如：6 个月）刷新令牌
2. 每当用户需要发出 API 请求时，都会检查令牌的到期时间。假设它尚未过期，用户使用该令牌与您的 API 对话并假设用户已获得授权），获取并发布必要的资源。
3. 如果令牌确实已过期，则需要刷新您的令牌，用户调用身份验证服务器（例如：POST / auth/token）并传递安全存储的刷新令牌。响应是发布的新访问令牌。
4. 使用该新令牌与您的 API 图像服务器通信。

可选（禁止用户）

我们如何禁止用户？使用该模型没有简单的方法可以做到这一点。增强功能：每个持久刷新令牌都包含一个黑名单字段，并且仅在刷新令牌未列入黑名单时才发布新令牌。

需要考虑的事项：

• 您可能想要轮换刷新令牌。为此，每次您的用户需要新的访问令牌时，将刷新令牌列入黑名单。这样刷新令牌只能使用一次。不利的一面是，您最终会获得更多刷新令牌，但可以通过清除列入黑名单的刷新令牌（例如：每天一次）轻松解决这一问题
• 您可能需要考虑设置每个用户允许发出的最大刷新令牌数（例如 10 或 20 个），因为您每次登录时都会发出一个新令牌（使用用户名和密码）。该数字取决于您的流量、用户可能使用的客户端数量（网络、移动设备等）以及其他因素。
• 您的身份验证服务中的注销端点可能会也可能不会将刷新令牌列入黑名单。需要考虑的事情。

Answer 6

我一直在使用JWT身份验证。在我的应用程序中工作正常。

有一种身份验证方法，将需要用户凭据。此方法将验证凭据并在成功的情况下返回访问令牌。

此令牌必须发送到请求标头中我的Web API中的所有其他方法。

这很容易实现，也很容易测试。