RESTAPI 认证

我正在构建一个将托管在服务器上的应用程序。我想为应用程序构建一个 API，以方便与任何平台(Web 应用程序，移动应用程序)的交互。我不明白的是，在使用 REST API 时，我们如何对用户进行身份验证。

例如，当用户已经登录，然后希望创建一个论坛主题。我如何知道用户已经登录？

224240 次浏览
小开
最佳答案

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

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

OAuth 是它能得到的最好的。OAuth 提供的优点是可撤销或可过期的令牌。关于如何实施，请参考以下内容: 来自评论的工作链接: http://www.ida.liu.se/~ TDP024/lab/hmacartile.pdf”rel = “ norefrer”> https://www.ida.liu.se/~tdp024/labs/hmacarticle.pdf

小开

我认为最好的方法是使用 OAuth2。谷歌一下，你会发现很多有用的文章来帮助你设置它。

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

希望能帮到你。

小开

例如，当用户登录时。现在让我们假设用户想创建一个论坛主题，我如何知道用户已经登录？

想想看-必须有一些握手，告诉你的“创建论坛”API，这个当前的请求是来自一个经过身份验证的用户。由于 REST API 通常是无状态的，所以状态必须持久化为 某个地方。使用 REST API 的客户机负责维护该状态。通常，它是以某种令牌的形式出现的，从用户登录开始就一直在传递这种令牌。如果信物是好的，你的要求就是好的。

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

我想在我之前的回答中加入一些实际的回应。尝试 Apache Shiro (或任何身份验证/授权库)。底线是，尽量避免自定义编码。一旦你集成了你喜欢的库(我使用 Apache Shiro，顺便说一下) ，你可以做以下事情:

  1. 创建类似于 /api/v1/login和 api/v1/logout的登录/注销 API
  2. 在这些登录和注销 API 中，使用 用户存储
  3. 结果是一个令牌(通常是 JSESSIONID) ，它被发送回客户端(web、 mobile 等等)
  4. 从现在开始，你的委托人随后打出的所有电话 将包括此令牌
  5. 假设您的下一个调用是对一个名为 /api/v1/findUser的 API 进行的
  6. 这个 API 代码要做的第一件事是检查令牌(“ is 此用户已通过身份验证?”)
  7. 如果答案是否定的，那么您将抛出一个 HTTP401状态 让他们来处理。
  8. 如果答案是“是”，则继续返回所请求的用户

就这样，希望能有所帮助。

小开

  1. 使用 HTTP 基本认证对客户端进行身份验证，但只将用户名/密码视为 临时会话令牌。

    会话令牌只是一个附加到 每个 HTTP 请求的头，例如: Authorization: Basic Ym9ic2Vzc2lvbjE6czNjcmV0

    上面的字符串 Ym9ic2Vzc2lvbjE6czNjcmV0只是用 Base64编码的字符串“ bobsession1: s3cret”(这是一个用户名/密码)。

  2. 为了获得上面的临时会话令牌，提供一个 API 函数(例如: http://mycompany.com/apiv1/login) ，它接受 master-username 和 master-password 作为输入，在服务器端创建一个临时 HTTP Basic Auth 用户名/密码，并返回令牌(例如: Ym9ic2Vzc2lvbjE6czNjcmV0)。这个用户名/密码应该是临时的，大约20分钟后过期。

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

如果使用 Java，SpringSecurity 库为实现上述方法提供了很好的支持

小开

我一直在使用 JWT 身份验证。

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

此令牌必须发送到请求标头中我的 WebAPI 中的每个其他方法。

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

小开

这是一个引导的方法。

身份验证服务发出使用秘密 也可以在你的 API 服务中找到签名的 JWT 令牌。之所以需要它们，是因为您需要验证收到的令牌，以确保您创建了它们。JWT 的好处是，如果不同的用户有不同的访问控制级别，那么它们的有效负载可以声明用户是 授权进入。

该体系结构使身份验证无状态: 不需要在数据库中存储任何令牌，除非您希望处理令牌黑名单(考虑禁止用户)。如果你需要扩大规模，无国籍是至关重要的。这也使您的 API 服务无需调用身份验证服务器，因为身份验证和授权所需的信息都在已发出的令牌中。

流(没有刷新令牌) :

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

这里有几个问题。也就是说，如果认证令牌落入坏人手中，恶意用户就可以无限制地假装自己是受影响的用户，并无限期地调用您的 API。为了处理这个问题，令牌有一个到期日期，客户机被迫在到期时请求新的令牌。该过期是令牌有效负载的一部分。但是如果令牌是短期的，我们是否每次都要求用户用他们的用户名和密码进行身份验证？没有。我们不希望每隔30分钟到1小时就要求用户输入密码，也不希望将该密码保存在客户机的任何位置。为了解决这个问题，我们引入了 刷新令牌的概念。它们是存活时间更长的令牌，只有一个用途: 充当用户的密码，对它们进行身份验证以获得新的令牌。缺点是，使用这种体系结构，身份验证服务器需要将这些刷新令牌保存在数据库中。

新流程(带刷新令牌) :

  1. 用户通过身份验证服务器(例如: POST/auth/login)进行身份验证，并接收 auth 服务器 附带一个长寿命的(如: 6个月)刷新令牌，他们存储安全生成和签名的 JWT 令牌
  2. 每当用户需要发出 API 请求时，就会检查令牌的过期时间。假设它还没有过期，用户使用该令牌与您的 API 进行通信，并假设用户得到授权) ，获取并发布必要的资源。
  3. 如果令牌确实已过期，则需要刷新令牌，用户调用身份验证服务器(例如: POST/auth/token)并传递安全存储的刷新令牌。响应是发出的新访问令牌。
  4. 使用该新标记与 API 映像服务器通信。

可选(禁止用户使用)

我们如何禁止用户？使用这个模型并不是一件容易的事情。增强: 每个持久化的刷新令牌都包含一个 被列入黑名单字段，并且只有在刷新令牌未被黑名单列出的情况下才会发出新的令牌。

需要考虑的事情:

  • 您可能需要旋转刷新标记。为此，每次用户需要新的访问令牌时，都要将刷新令牌列入黑名单。这样刷新令牌只能使用一次。缺点是你最终会得到更多的刷新令牌，但是这个问题可以通过清除黑名单中的刷新令牌来轻松解决(例如: 一天一次)
  • 您可能需要考虑为每个用户设置最大允许刷新令牌数(比如10或20) ，因为每次用户登录时您都会发出一个新令牌(使用用户名和密码)。这个数字取决于你的流量，一个用户可以使用多少客户端(网络，手机等)和其他因素。
  • 身份验证服务中的注销端点可能会或可能不会将刷新令牌列入黑名单。

提交答案