我正在开发具有紧密耦合的SPA的REST API，作为上述REST API的唯一客户端。
假设SPA在myservice.com可用，而api在myservice.com/api下。它们基本上是一项服务，仅在代码级别拆分，并部署在不同的根路径中。
我现在用于安全性的是具有ROPC（用户名/密码）授予类型的OAuth2。
问题来了。我一直到处都读到ROPC不安全，不应使用。那我该怎么用呢？
我的REST API充当授权服务器，但它本身没有任何Web界面。因此，任何涉及重定向的流程都没有任何意义。 SPA和API紧密相连，以至于对于最终用户而言，它们基本上是一个应用程序。没有第三方。
我可以将简单的登录表单添加到可以使用myservice.com/login的API中。但是，我努力地看到会有所作为。
此应用程序中的安全性非常重要。
这是我的问题：
在这种情况下使用ROPC真的很危险吗？
什么是验证和授权的理想方法？
或者OAuth2在没有第三方的情况下是完全多余的？
使用的技术：
服务器：Spring Boot
答案 0 :(得分：4)
在这种情况下使用ROPC真的很危险吗？
不，不是真的提供：
a）您不存储用户密码-也许只使用它来获取初始访问权限和刷新令牌-尽管使用SPA可能会很麻烦。
b）您的SPA客户端和资源API归您所有，因此您无需用户同意对SPA进行特定范围的访问。
什么是验证和授权的理想方法？
这取决于很多事情。没有足够的信息来尝试回答这个问题。 OAuth2.0（带有可能已实现的授权服务器）是此处示例的一种很好的方法。
或者OAuth2在没有第三方的情况下是完全多余的？
如果其他应用程序会及时使用您的API，那么OAuth2.0可能是一个不错的选择。否则，您可能会使用更简单的解决方案，例如会话Cookie，因为它们都位于同一域中。
答案 1 :(得分：2)
可以从OAuth 2.0 specification (RFC6749)本身中获取答案。它定义了ROPC赠款何时适合，
4.3. Resource Owner Password Credentials Grant
资源所有者密码凭证授予类型适用于 案例，其中资源所有者与 客户端，例如设备操作系统或特权较高的用户 应用。授权服务器在以下情况下应格外小心 启用此授予类型，并且仅在没有其他流时才允许它 viabl。
根据您的解释，您与SPA和后端紧密结合。另外，您将授权服务器和资源服务器都构建为一个。这完全是acceptable implementation。
授权服务器 可以是与资源服务器相同的服务器，也可以是单独的实体。
所以现在重要的是弄清楚为什么要在方案中使用OAuth 2.0。
如果您使用OAuth 2.0获取令牌，请按照OAuth 2.0规范中的定义维护令牌，那么这完全是橡木桶。但是，如果您这样做是为了顺应趋势，请三思。
OAuth 2.0实现本身具有复杂性。您必须维护用户身份，维护令牌并更新令牌。您将自己构建一个完整的授权服务器。但这也有一些优点。
例如，同一授权服务器可用于为以后的集成/辅助应用程序发行令牌。 IMO，OAuth 2.0的使用使集成变得容易，因为它定义了发行令牌，续签和吊销令牌的协议。 但是在这种集成方案中，可能会要求您使用其他赠款。尽管如此，您的API已获得令牌授权，您只需要担心新的集成/应用程序如何获得令牌。这比使用经过身份验证的会话更好
回到您的问题，
问：在这种情况下使用ROPC真的很危险吗？
如前所述，如果客户端和授权服务器之间存在正确的信任关系，那就很好。但是请注意，拥有授权服务器会带来复杂性。
问：进行身份验证和授权的最佳方法是什么？
OAuth 2.0用于授权。您获取访问令牌，并使用它们对受保护的API进行授权。您可以从API中进行令牌验证，以检测正确的访问级别/权限。
如果要身份验证，则必须使用OpenID Connect。它是OAuth 2.0的扩展协议。并允许您的应用基于ID令牌对最终用户进行身份验证。您可以使用ROPC授权来获取ID令牌。
问：或者OAuth2在没有第三方的情况下是完全多余的？
不一定。它允许您以现代的标准方式设计API。谁知道未来会怎样（再次考虑整合方案）。遵循协议可以轻松实现。
仅提供建议，请严格遵循规格。不要发明自己的协议/适配。这使事情变得难以维护。