使用 OAuth2 保护单体私有 REST api？ [关闭]

Posted 2023-02-26

【中文标题】使用 OAuth2 保护单体私有 REST api？ [关闭]

【英文标题】：Using OAuth2 for securing a monolith private REST api? [closed]

【发布时间】：2019-07-02 02:40:55

【问题描述】：

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

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

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

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

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

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

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

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

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

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

我真的需要更多关于这方面的建议，我已经花了好几个星期了。

谢谢。

【问题讨论】：

嗨！只是想知道你用了什么解决方案？我有一个类似的问题正在尝试解决。

这个问题花了很多时间，所以我决定使用带有 JSESSIONID 的 Basic Auth。如果配置正确，那也是相当安全的。 @匿名

【参考方案1】：

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

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

对于授权 API 端点，有很多解决方案。最常见的是secret key value 和 JWT。秘钥有很多弱点，这里就不多说了。

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

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

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

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

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

验证的高计算成本

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

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

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

【讨论】：

对不起，我忘了提，是的，我需要身份验证和授权。

如果你需要认证和授权，那么你的选择应该是OAuth。 JWT 确实提供了身份验证，除非您围绕 JWT 包装身份验证系统。

谢谢。我读到 OAuth 用于授权并向层添加身份验证，OpenId Connect 是工具。但是当我对 OAuth（使用 Java Spring 安全框架）进行一些测试时，我配置了 Authorization Server 和 Resource Server，这足以查看数据库中的凭据（即身份验证）以及授权部分。 Resource Server 对此负责。如果通过这么多配置完成身份验证，为什么还要担心 OpenId 连接？

我在回答中介绍了 OAuth 和 OIDC。您需要具体说明哪个身份提供者。大多数已将 OIDC 集成到 OAuth 中。请注意，OIDC 是位于 OAuth 之上的一个层，它本身并不是一个单独的服务。 OIDC 为 OAuth 的“授权”提供“身份”。我已经回答了你的问题。关闭这个，然后打开一个非常具体的新问题（意思是在 SO 上的每个帖子问一个问题）。