独立休息服务的Spring Boot安全性[重复]

Posted 2023-02-27

【中文标题】独立休息服务的Spring Boot安全性[重复]

【英文标题】：Spring boot security for standalone rest services [duplicate]

【发布时间】：2020-06-16 05:32:18

【问题描述】：

假设我正在构建一个具有端点的 Spring Boot REST 服务

/users/myself
/users/myself/books

我有用户和书籍存储在数据库中。

当然，您需要通过身份验证才能访问这些资源，但是每当我搜索“Spring Rest 安全性”时，它基本上都会为您提供三个选项

基本认证 OAuth2 JWT 令牌

而且你几乎看不到有人提议使用会话进行身份验证，这对我来说没有意义，尤其是在小型独立服务中。原因如下：

基本身份验证绝不是身份验证的好主意，因为这需要将 username:password 存储在某些存储中以保持用户身份验证。 OAuth2 似乎无法用于我们没有专用授权服务器的这种用例。在 Spring Boot 应用程序中内置授权服务器对我来说似乎有点矫枉过正，并且与会话相比没有任何优势。 如果你真的创建了一个无状态的 JWT 令牌，那么就会带来大量的安全问题 - 无法撤销令牌。如果您在 DB 中保留一个令牌列表，那么它就不再是无状态的 REST 服务，并且本质上就像会话一样，除了您必须构建大量自定义逻辑以使其在 Spring 中的 OOTB 会话处理时工作。

那么为什么不使用会话进行身份验证呢？

【问题讨论】：

这能回答你的问题吗？ security for web applications session vs token

【参考方案1】：

通常的动机是围绕 API 客户端的安全性以及它们如何与您的 API 连接。尤其是当他们是公共客户时，现代安全可能会成为热门话题。

浏览器用户界面 移动用户界面

OAuth 技术可能会简化和外部化您的安全性，例如我的initial tutorial，在 UI 或 API 中几乎没有安全代码。 API 是无状态的，并且状态被外部化到一个低成本且高度可用的云授权服务器。

使用正确的设计，令牌是短暂的（无需撤销），您编写的代码将比使用会话时简单得多。它将支持集群环境中的现代托管并且更便携。

在架构上还有很多其他好处——尽管你说得对，技术挑战是正确的。因此，通常需要选择这种飞跃的时间并与您的利益相关者达成一致。