我可以在 SPA 中使用资源所有者密码流吗？

Question

我正在尝试在我的解决方案中实现身份验证/授权。我在 API Gateway 下有一堆后端服务（包括身份服务）、“前端后端”服务和 SPA（React + Redux）。我已经阅读了有关 OAuth2.0/OpenIdConnect 的信息，但我不明白，为什么我不应该使用资源所有者密码流？

客户端（我的前端服务器的后端）是绝对可信的，我可以简单地将用户登录名/密码发送到服务器，然后将它们转发到身份服务器，接收访问令牌 && 刷新令牌并将刷新令牌存储在内存中（ session、Redis 等），并将访问令牌发送到 SPA，SPA 将其存储在本地存储中。如果 SPA 将使用过期的访问令牌发送请求，服务器将使用刷新令牌请求新的请求，并使用新的访问令牌将请求转发到 API Gateway。

我认为在我的情况下，带有重定向的流程可以提供有价值的用户体验，但过于复杂。

我误解了什么？如果我如上所述实施身份验证/授权，我会遇到什么坑？

Answer 1

OAuth 2.0 规范的introduction section 提供了一个关于它试图解决的问题的关键信息。我在下面突出显示了一个部分，

在传统的客户端-服务器身份验证模型中，客户端 请求访问受限的资源（受保护的资源） 服务器通过使用资源所有者的服务器进行身份验证 凭据。为了提供第三方应用程序访问 受限资源，资源所有者与 第三方

总而言之，OAuth 想要提供的是一个授权层，它消除了将最终用户凭据暴露给第三方的要求。为了实现这一点，它提出了几个流程（例如：授权代码流程、隐式流程等）来获取足以访问受保护资源的令牌。

但并非所有客户都能采用这些流程。这就是 OAuth 规范引入 ROPF 的原因。这是从以下提取中突出显示的，

资源所有者密码凭据授予类型适用于 资源所有者与资源所有者有信任关系的情况 客户端，例如设备操作系统或高特权 应用程序。授权服务器应特别注意何时 启用 此授权类型，并且仅在其他流不可用时才允许 可行。

根据您的解释，您与客户之间存在信任关系。而且您的流程似乎运行良好。但从我的角度来看，我看到了以下问题。

信任

信任存在于最终用户和客户端应用程序之间。当您发布并将其用作产品时，您的最终用户会信任您的客户并共享他们的凭据吗？例如，如果您的身份服务器是 Azure AD，最终用户会与您的客户端共享 Azure 凭据吗？

如果您使用的是单个身份服务器，信任可能不是问题，而且它将是您唯一使用的身份服务器。这给我们带来了下一个问题，

支持多个身份服务器

OAuth 2 和 OpenID Connect 的一个优势是能够使用多个身份服务器。例如，您可以在 Azure AD、Identityserver 或客户选择的其他身份服务器之间移动（例如：- 他们已经在内部使用并且他们希望您的应用程序使用它）。现在，如果您的应用程序想要使用此类身份服务器，最终用户将不得不与您的客户端共享凭据。有时，这些身份服务器甚至可能不支持 ROPF 流。信任再次成为问题。！

解决方案？

嗯，我看到了一个很好的流程，你可以使用。您有一个前端服务器和一个后端服务器。我相信你的客户是两者的结合。如果是这种情况，您可以尝试采用授权代码流。确实，您的前端是 SPA。但是您有一个可以用来获取令牌的后端。唯一的挑战是将前端 SPA 与后端连接以进行令牌响应（将访问令牌传递给 SPA 并将其他令牌存储在后端）。使用这种方法，您可以避免上述问题。