我有一个面向公众的应用程序，它使用ASP。NET Core Identity存储第一方登录信息，无意使用Facebook或谷歌等第三方IdP。我想在React中构建前端，该应用程序包括一个API，该API面向几个后端服务，我需要将JWT转发到这些服务以获得授权。
到目前为止的计划是使用Identity Server 4作为项目的IdP，将其支持到ASP中。NET核心标识数据存储。
目前的指导是将授权代码流与PKCE一起使用，这将需要重定向到IdP、两组样式等
在这种情况下，在不存在第三方IdP的情况下，是否仍然强烈反对授予资源所有者密码？从表面上看，它给人一种更整洁的体验：
- 用户填充基于React的登录页面
- XHR POST到具有凭据的IdP(模块化MFA质询(
- IdP返回一个访问令牌，React应用程序随后将其用于未来对API的请求
在这种特定情况下，通过寻求ROPC拨款，与接受基于重定向的IdP流中涉及的需求和重复相比，我将引入哪些问题？
工作量
这是一个大问题。除了登录屏幕，你还必须确保忘记密码等其他区域也能工作。如果你构建了第二个应用程序，你也需要让它在那里工作。
可扩展性
本文总结了问题领域。其中之一就是无法扩展登录解决方案。
安全
令牌刷新(通常(不适用于ROPG，这会导致访问令牌寿命长和其他复杂性。此外，对于OAuth，建议应用程序永远不会看到凭据。
从安全角度来看，重定向用户看起来更现代——所有大型提供商都这样做——比如谷歌、微软。
桥接解决方案
正如你所说，如果密码对你的应用程序是私有的，这可能不是世界上最糟糕的事情。不过，在你的应用程序中捕获用户的谷歌密码将是一件坏事。
ROPG有它的用途，但没有太多的未来-它在OAuth 2.1中被弃用，提供商将取消它。因此，我也推荐LalitaCode的建议。。
如果需要，您可以使用PKCE为授权代码流创建一个基于React的Identity Server登录页面，而不是使用MVC UI。这只是额外的工作，而且很复杂。我建议您将Identity Server MVC UI的样式设置为与前端SPA完全相同。这是我使用Identity Server(使用Angular作为前端(进行项目时采用的最简单的方法和路径。