现在密码授予类型已被弃用，在您只有 1 个客户端并且它是您的（因此您可以信任该客户端）的情况下，您使用什么？
我知道授权代码现在被认为是最佳实践，因为您不会在向服务器发出请求的标头中泄露用户的凭据。但我发现从用户的角度来看，将它们重定向到授权服务器（也是您的）并再次将它们重定向回客户端（也是您的）确实很不方便。
我只想在全栈应用程序的典型情况下有一个简单的基于表单的登录/注册选项，其中前面是 next.js 应用程序，后面是一个宁静的 Spring Boot 应用程序，但我不知道是什么是最好的决定，我应该实际使用什么。我还考虑实现我自己的系统（用户将他的凭据提供给服务器，服务器将这些凭据发送到服务器，服务器将提供客户端ID和秘密，客户端将从服务器获取访问令牌并使用他的ID刷新令牌）秘密，使用 JWT 实现所有这些），但它确实看起来像是相同 OAuth2 密码授予类型的实现，我真的不想创建一个锤子而不是一个表
代码流是推荐的解决方案。如果您想坚持使用 OAuth，则应该使用它。我不同意重定向给用户带来不便。大多数时候，用户甚至不会注意到她被重定向到另一个页面。
我只想在全栈应用程序的典型情况下有一个简单的基于表单的登录/注册选项
您刚刚自己回答了您的问题:) 如果您不需要 OAuth，请不要使用它。只需坚持使用基于 cookie 的普通会话，并让您的用户使用用户名和密码登录即可。
基于 OAuth 的独立授权服务器为您提供的一件事是能够轻松扩展用户登录的方式。例如，如果在某些时候您想要添加“使用 Google 登录”或 2-因素身份验证，那么您将必须在后端服务器和前端实现对其的支持。使用单独的授权服务器，您只需在服务器本身中执行此操作即可。如果您使用产品（而不是构建自己的授权服务器），那么通常您只需配置一些选项就可以添加新的身份验证方法。不过，如果您觉得不需要这些，请坚持使用在后端实现的简单 HTML 表单。