标题翻译
Spring boot security for standalone rest services
问题
假设我正在构建一个Spring Boot REST服务，其中包含以下端点：
/users/myself
/users/myself/books
我在数据库中存储了用户和书籍。
当然，要访问这些资源，您需要进行身份验证，但无论我搜索“Spring Rest security”，基本上都会给出三个选项：
- 基本认证
- OAuth2
- JWT令牌
几乎看不到有人提议在身份验证中使用会话，这对我来说毫无意义，特别是在小型独立服务中。以下是原因：
- 基本认证从来都不是一个好主意，因为这将需要在某个存储中存储用户名：密码以保持用户认证状态。
- OAuth2 在这种情况下似乎无法使用，因为我们没有专用的授权服务器。而且在Spring Boot应用程序中内置授权服务器对我来说似乎过于繁琐，并且与会话相比没有任何优势。
- 如果您真的创建了无状态的JWT令牌，那么会带来大量的安全问题 - 无法撤销令牌。如果您在数据库中保留令牌列表，那么它就不再是无状态的REST服务，实质上的行为类似于会话，只是您必须构建大量的自定义逻辑使其正常工作，而会话处理在Spring中是开箱即用的。
那么，为什么不使用会话进行身份验证呢？
英文翻译
Let's say I'm building a Spring Boot REST service which has endpoints
/users/myself
/users/myself/books
and I have users and books stored in the DB.
Of course you need to be authenticated to access these resources, but whenever I search for "Spring Rest security" it gives you basically three options
- Basic Auth
- OAuth2
- JWT tokens
And you barely see anyone proposing using sessions for authentication, which doesn't make sense to me, especially in small standalone services. And here is why:
- Basic auth is never good idea for authentication, because that would require storing username:password in some storage to keep user authenticated.
- OAuth2 seems to be unusable for this use case where we don't have a dedicated authorization server. And having a built-in authorization server in a spring boot app seems an overkill to me and serves no advantage over sessions.
- If you really create a stateless JWT token, then that brings a ton of security issues - not able to revoke the token. If you keep a list of tokens in DB then it's no longer a stateless REST service and essentially acts like sessions, except you have to build ton of custom logic to make it work while session handling comes OOTB in Spring.
So why the heck not use sessions for authentication?
答案1
得分: 0
通常的动机是为了API的客户端安全性以及它们与API的连接方式。特别是在公共客户端的情况下，现代安全性可能成为一个热门话题。
- 浏览器界面
- 移动设备界面
OAuth技术可以潜在地简化和外部化您的安全性，就像在我的初始教程中所述，几乎没有安全代码存在于UI或API中。API是无状态的，状态被外部化到成本低廉且高可用的云授权服务器中。
通过正确的设计，令牌的生命周期很短（无需吊销），您编写的代码将比使用会话时简单得多。它将支持在集群环境中进行现代托管，并且更具可移植性。
从架构上讲，还有很多其他好处 - 虽然您是对的，存在技术挑战。因此，通常是选择合适的时机进行这种飞跃，并与相关利益相关者达成一致。
英文翻译
Often the motivation is around security for your API's clients and how they connect with your API. Especially when they are public clients, where modern security can be a hot topic.
- Browser UIs
- Mobile UIs
OAuth tech can potentially simplify and externalise your security, as in my initial tutorial, where there is almost zero security code in either UI or API. The API is stateless and state is externalised to a low cost and highly available Cloud Authorization Server.
With the right designs, tokens are short lived (with no need for revocation) and the code you write will be much simpler than when you use sessions. It will support modern hosting in clustered environments and be more portable.
Architecturally there are quite a few other benefits - though you are right that there are technical challenges. So it is often a case of choosing the time for this kind of leap and agreeing it with your stakeholders.
专注分享java语言的经验与见解，让所有开发者获益！
评论