我正在开发带有紧密耦合的水疗中心的REST API，作为上述REST API的唯一客户端。
假设该水疗中心可在myservice.com上找到，并且API在myservice.com/api下。它们基本上是一项服务，只是在代码级别分开，并在不同的根路径上部署。
我现在使用的安全性是用ROPC（用户名/密码）授予类型的OAuth2。
这是问题所在。我一直在阅读任何地方，ROPC不安全，不应使用。那我应该使用什么？
我的REST API充当授权服务器，但没有任何Web接口本身。因此，任何涉及重定向的流程都没有意义。水疗和API非常紧密，以至于最终用户基本上是一个应用程序。没有第三方。
我可以在myservice.com/login上的API中添加简单的登录表单。但是我很难看到会带来的差异。
此应用程序中的安全性非常重要。
这是我的问题：
在这种情况下，使用ROPC真的很危险？
什么是身份验证和授权的理想方法？
或者也许没有第三方的OAuth2是完全多余的？
使用的技术：
服务器：Spring Boot
在这种情况下，使用ROPC真的很危险？
不，没有真正提供：
a）您不存储用户的密码 - 也许只使用它来获取初始访问和刷新令牌 - 尽管对于水疗中心可能很棘手。
b）您的水疗客户端和资源API是您所有的，因此您不需要用户同意对SPA的特定范围访问。
什么是身份验证和授权的理想方法？
这取决于很多事情。没有足够的信息来回答这个问题。OAuth2.0（可能具有可能实现的授权服务器）是您在此处使用的示例的一个很好的方法。
或者也许没有第三方的OAuth2是完全多余的？
如果其他应用程序会及时使用您的API，则OAuth2.0可能是一个很好的电话。否则，您可能可以使用更简单的解决方案，例如会话cookie作为所有位于同一域上的cookie。
可以从OAuth 2.0规格（RFC6749）本身中取出答案。它定义了ROPC授予何时适合，
4.3。资源所有者密码凭据授予
资源所有者密码凭据赠款类型适用于案例资源所有者与客户端，例如设备操作系统或高度特权应用。授权服务器应在启用此赠款类型，仅在其他流量不在时才允许viabl。
根据您的解释，您与水疗中心和后端紧密结合。另外，您同时将授权服务器和资源服务器构建为一台。这是完全可以接受的实现。
授权服务器可能与资源服务器或单独的实体相同。
现在重要的是要清除为什么在情况下使用OAuth 2.0。
如果您使用的是OAuth 2.0获取令牌，请通过OAuth 2.0规范定义它们，则将其完全橡木。但是，如果您这样做是为了遵循趋势，请三思而后行。
oauth 2.0实现其自身复杂性。您必须维护用户身份，维护令牌并续订它们。您正在自己构建完整的授权服务器。但这也有一些优势。
例如，可以使用相同的授权服务器为将来的集成/辅助应用程序发布令牌。IMO，OAuth 2.0的使用使集成变得容易，因为它定义了发行令牌，续订和撤销它们的协议。，但是在这种集成方案中，您可能需要使用其他赠款。尽管如此，您的API已获得代币的授权，您只需要担心新的集成/应用程序如何获得令牌即可。这比使用身份验证的会话
更好回到您的问题，
问：在这种情况下，使用ROPC真的很危险？
正如所解释的，如果 client 和授权服务器之间存在正确的信任关系，则很好。但是要注意复杂性，因此拥有授权服务器。
问：身份验证和授权的理想方法是什么？
oauth 2.0用于授权。您获得访问令牌并使用它们来授权您受保护的API。从API中，您进行令牌验证以检测正确的访问级别/权限。
如果您想要 authenticaiton ，则必须使用OpenID Connect。它是从OAuth 2.0延伸的协议。并允许您的应用程序根据ID令牌对最终用户进行身份验证。您可以使用ROPC Grant获得ID令牌。！
Q：或者也许没有第三方的OAuth2是完全冗余的？
不一定。它使您可以以现代的标准方式设计API。谁知道未来（再次是集成方案）。遵循协议可以简单。
只有建议，密切遵守规格。不要发明自己的协议/改编。它使事情变得更难维护。