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

Question

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

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

我认为在我的情况下，带有重定向的流可以提供有值(value)的用户体验，而且太复杂了。

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

Answer 1

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

In the traditional client-server authentication model, the clientrequests an access-restricted resource (protected resource) on theserver by authenticating with the server using the resource owner'scredentials. In order to provide third-party applications access torestricted resources, the resource owner shares its credentials withthe third party

总之，OAuth 想要提供的是一个授权层，它消除了将最终用户凭据暴露给第三方的要求。为了实现这一点，它提供了几个流程(例如:授权代码流程、隐式流程等)来获取足以访问 protected 资源的 token 。
但并非所有客户都能够采用这些流程。这就是 OAuth 规范引入 ROPF 的原因.从以下提取中突出显示了这一点，

The resource owner password credentials grant type is suitable incases where the resource owner has a trust relationship with theclient, such as the device operating system or a highly privilegedapplication.The authorization server should take special care whenenabling this grant type and only allow it when other flows are notviable.

根据您的解释，您与客户有信任关系。你的流程似乎工作正常。但从我的角度来看，我看到了以下问题。
信任
信任是在最终用户和客户端应用程序之间。当您将其作为产品发布并使用时，您的最终用户会信任您的客户并分享他们的凭据吗？例如，如果您的身份服务器是 Azure AD，最终用户是否会与您的客户端共享 Azure 凭据。？
如果您使用单个身份服务器，信任可能不是问题，它将是您将使用的唯一身份服务器。这给我们带来了下一个问题，
支持多个身份服务器
使用 OAuth 2 和 OpenID Connect 获得的一项优势是能够使用多个身份服务器。例如，您可以在 Azure AD、Identityserver 或客户选择的其他身份服务器之间移动(例如:- 他们已经在内部使用并且他们希望您的应用程序使用它)。现在，如果您的应用程序想要使用此类身份服务器，最终用户将必须与您的客户端共享凭据。有时，这些身份服务器甚至可能不支持 ROPF 流。再次信任成为一个问题。!
一个办法 ？
好吧，我看到了一种您可以使用的良好流程。您有一台前端服务器和一台后端服务器。我相信您的客户是两者的结合。如果是这种情况，您可以尝试采用授权代码流。确实，您的前端是一个 SPA。但是您有一个可以用来获取 token 的后端。唯一的挑战是将前端 SPA 与后端连接以进行 token 响应(将访问 token 传递给 SPA 并将其他 token 存储在后端)。使用这种方法，您可以避免上述问题。