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

Question

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

客户端（前端服务器的后端）是绝对受信任的，我可以简单地向用户发送登录名/密码到服务器，然后将其转发到身份服务器，接收访问令牌和刷新令牌，并将刷新令牌存储在内存中（会话，Redis）等等），并将访问令牌发送到SPA，然后将其存储在本地存储中。如果SPA将发送带有过期访问令牌的请求，则服务器将使用刷新令牌请求一个新请求，并将请求与新访问令牌一起转发给API网关。

我认为就我而言，带有重定向的流可以提供有价值的用户体验，并且过于复杂。

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

Answer 1

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

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

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

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

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

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

相信

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

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

支持多个身份服务器

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

一个办法 ？

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