我正在用spring Boot 和react构建我的第一个web应用程序。现在我专注于安全方面。该应用程序使用jwt令牌。当用户登录时，后端在Authorization头沿着一个短期访问令牌和一个存储在仅限http的cookie中的长期刷新令牌进行响应。然后，访问令牌存储在本地存储中，并用于发出后续请求。cookie的（cookie包含刷新令牌）路径被设置为负责刷新访问令牌的端点，这样它就不会沿着前端发出的每个请求一起发送。如果访问令牌过期，则后端以401状态响应，前端向刷新端点发出请求。
考虑到它是一个展示应用程序，这种方法有效吗？或者我应该使用OAuth2和“后端用于前端”或“BFF”？
2条答案
按热度按时间jrcvhitl1#
考虑到它是一个展示应用程序，这种方法有效吗？或者我应该使用OAuth2和“后端用于前端”或“BFF”？
我们不能说，这一切都是关于你是谁显示套管它。
如果它是在显示，你可以安全方面，我肯定不会显示它，因为它只会显示，你得到你的知识，从以下穷人的博客，你没有真实的知识，为什么你不应该建立这样的登录在生产环境中。
OAuth 2.0 Security Best Current Practice文档建议不要完全使用 * 隐式流 *，因为在HTTP重定向中返回访问令牌而不确认客户端已收到令牌的风险。
如果您显式地使用JWT令牌，则在将令牌直接分发给浏览器时需要考虑其他严重的风险。
Spring Security中没有这样的实现，这是有充分理由的。
这样的例子不胜枚举。
JWT旨在用于私有网络，以减少对发布者的请求数量。它们应该是短暂的（分钟）以执行一次性请求。它们从未打算取代会话。
Springs Implementation guidelines for Browser-Based Apps (SPA)推荐像BFF这样的私人客户。
像Google、Facebook等大公司不向浏览器公开令牌，他们在客户端使用BFF模式和cookie，主要遵循OpenID连接标准。
所以，如果你打算表明你知道安全，我会显示适当的安全。
ghhaqwfi2#
access/refresh token完全没问题！只有当你想让你的用户通过其他身份提供商服务（如Google）进行身份验证时，你才可以使用Oauth2.0。