2

也许这个问题似乎是基于意见的，但我在决定保护 RESTful API时遇到了困难。

首先，我的用例：
我的应用程序非常简单：前端是使用 React.js（用于浏览器客户端）编写的，它将使用 RESTful API 从数据库（或其他东西）获取数据。API 是使用Spring 框架构建的。

此 API 不是公共 API，它只有一个客户端（目前，以后将是移动应用程序）。

现在让我们来谈谈安全问题。显然，我想保护我的 API，我使用 Spring-security 作为这项工作的工具。在学习的最初几天，我只知道基本身份验证。但是，当我继续阅读更安全的选项时，我学到了一些新奇的术语：

  1. 基于令牌的身份验证，使用 JWT
  2. OAuth2
  3. OpendId 连接

当我阅读更多来自Auth0、Okta等的博客时，我把一切都搞砸了。这让我三思而后行，是否应该使用 OAuth 来保护 REST API（不公开）。此外，几乎所有关于 OAuth 的博客都以社交登录为例。这让我更加困惑，OAuth 是为了让第三方应用程序访问您的 API。就是这样，不适用于我的用例。

然后我从一些渠道和博客中询问了一些专家，一些人说基本身份验证对于安全性来说已经足够了（使用 https），我应该避免使用 OAuth 来满足这么小的要求。其他人则相反，称 Basic-Auth 存在安全漏洞。

让我们考虑一下 OAuth 对我来说是完美的，但在这种情况下，我的授权服务器将驻留在哪里？因为教程仅通过将代码保持在同一层来解释授权服务器。没有单独的项目或其他东西。

JWT 对我的用户案例也有一些负面评价：

  1. 它们不能被撤销，只会自行过期。不是没有安全感吗？
  2. 与会话令牌或 cookie 相比，它们的大小很大
  3. 验证的高计算成本

我真的需要更多关于这方面的建议，这已经花了我很多周的时间。

谢谢。

4

1 回答 1

3

真正的答案取决于您的问题中没有的信息。例如，您需要identity verification还是只是authorizingAPI 访问？

今天的 OAuth 和 Open ID Connect (OIDC) 对于大多数服务（例如 Google 登录）来说基本上是相同的。OIDC 在授权之上添加了一个身份层。如果您需要验证用户的身份、记录他们的活动、控制每个用户的资源等，这就是您的解决方案。

对于授权 API 端点，有很多解决方案。最常见的是secret key value和 JWT。密钥有很多弱点，所以我不会在这里触及。

授权 API 端点的一种非常常见的方法是使用 JWT 令牌和Authorization: Bearer TOKENHTTP 标头。我现在将尝试回答您对使用 JWT 令牌的担忧。这里我只提到 Signed-JWT 令牌。

它们不能被撤销，只会自行过期。不是没有安全感吗？

可以通过撤销签名证书来撤销 JWT 令牌。这需要创建一个证书撤销服务器，所以这并不常见。一种改进的方法是创建short-lived令牌。典型的到期时间为 60 分钟（3600 秒），但您可以为任何时间段创建令牌。当令牌过期时，客户端请求一个新的，您的后端可以授权或拒绝。

与会话令牌或 cookie 相比，它们的大小很大

什么是巨大的？您可以从几个字节（签名加上数据的大小）创建任意大小的令牌，或者在令牌中包含大量信息。除非您的令牌在大小上失控，否则这对大多数实现都无关紧要。

验证的高计算成本

您再次使用了一个模糊的术语。验证签名 JWT 的计算成本并不高，除非您使用诸如物联网（已经在使用 SSL 证书、加密等）之类的小型设备，或者您需要每分钟处理数百万笔交易。换句话说，除非您有充分的理由担心 CPU 周期，否则不要担心它们会提高安全性。

让我们考虑一下 OAuth 对我来说是完美的，但在这种情况下，我的授权服务器将驻留在哪里？

您的 OAuth 2.0 授权服务器可以驻留在您想要的任何位置。实现 OAuth 非常简单，并且有许多库可以为您管理详细信息。您的授权服务器可以是后端的一部分，也可以是单独的服务器等。您甚至可以将其完全外包给身份提供商，例如 Google Login、Auth0、Okta 等。

于 2019-02-07T22:21:59.137 回答