我正在尝试在我的解决方案中实施身份验证/授权。我在API网关下有很多后端服务（包括身份服务），“后端后端”服务和SPA（React + Redux）。我已经阅读了有关OAuth2.0 / OpenIdConnect的信息，但我不明白，为什么我不应该使用资源所有者密码流？
一个客户端（我前端服务器的后端）是绝对受信任的，我可以简单地将用户登录名/密码发送到服务器，然后将其转发到身份服务器，接收访问令牌和刷新令牌，并将刷新令牌存储在内存中（会话，Redis等），然后将访问令牌发送到SPA，并将其存储在本地存储中。如果SPA将使用过期的访问令牌发送请求，则服务器将使用刷新令牌请求新的请求，并使用新的访问令牌将请求转发到API网关。
我认为，带有重定向的流可以提供有价值的用户体验，并且过于复杂。
我误解了什么？如果如上所述实现身份验证/授权，我会遇到哪些困难？
答案 0 :(得分：2)
OAuth 2.0规范的introduction section提供了有关要解决的问题的关键信息。我在下面突出了一个部分，
在传统的客户端-服务器身份验证模型中，客户端 请求对服务器进行访问限制的资源（受保护的资源） 通过使用资源所有者的身份与服务器进行身份验证 凭据。为了提供第三方应用程序访问 受限制的资源，资源所有者与 第三方
作为总结，OAuth想要提供的是一个授权层，该授权层消除了将最终用户凭据公开给第三方的要求。为此，它提出了几种流程（例如：授权代码流程，隐式流程等），以获取足以访问受保护资源的令牌。
但并非所有客户都能采用这些流程。这就是OAuth规范引入ROPF的原因。在以下提取中突出显示了这一点，
资源所有者密码凭证授予类型适用于 资源拥有者与 客户端，例如设备操作系统或特权较高的客户端 应用程序。授权服务器在使用时应格外小心 启用此授予类型，并且仅在没有其他流时才允许 可行。
根据您的解释，您与客户之间具有信任关系。而且您的流程似乎运行良好。但是从我的角度来看，我看到了以下问题。
信任
信任在最终用户和客户端应用程序之间。当您发布并将其用作产品时，最终用户会信任您的客户端并共享其凭据吗？例如，如果您的身份服务器是Azure AD，最终用户将与您的客户端共享Azure凭据吗？？
如果您使用单个身份服务器，则信任可能不是问题，它将是您将永远使用的唯一身份服务器。这带来了下一个问题，
支持多个身份服务器
使用OAuth 2和OpenID Connect获得的一个优势是可以使用多个身份服务器。例如，您可以在Azure AD，Identityserver或其他由客户选择的身份服务器之间移动（例如：它们已经在内部使用，并且希望您的应用程序使用它）。现在，如果您的应用程序要使用此类身份服务器，则最终用户将必须与您的客户端共享凭据。有时，这些身份服务器甚至可能不支持ROPF流。信任再次成为一个问题。！
解决方案？
好吧，我看到您可以使用的一个很好的流程。您有一台前端服务器和一台后端服务器。我相信您的客户是两者的结合。如果是这种情况，您可以尝试采用授权代码流。确实，您的前端是SPA。但是您拥有可以用来获取令牌的后端。唯一的挑战是将前端SPA与后端连接起来以进行令牌响应（将访问令牌传递给SPA并将其他令牌存储在后端中）。使用这种方法，可以避免上述问题。