我正在开发的项目包括Web API，单页反应应用程序和移动应用程序。从每个客户端，用户需要提供他们的用户名和密码才能访问Web API的受保护部分。我已经设置了一个Identity Server 4身份验证服务器，它使用我自己的 IProfileService 和 IResourceOwnerPasswordValidator 接口的实现，因为我使用的是ASP.NET核心身份。这允许Identity Server访问ASP.NET核心标识 UserManager ， RoleManager 和 SignInManagers ，以确定提供的用户名和密码是否有效。
我一直用于所有这些的授权类型是“ResourceOwnerPassword”类型。我还没有将授权完全集成到单页面应用程序中，但我可以将用户的用户名和密码传递给身份服务器，并生成一个令牌，我可以将其添加到我的API请求的标头中。
我对Identity Server和相关技术做了更多研究，因为我对这一切都是新手。似乎不希望使用ResourceOwnerPassword授权类型。从我可以看出，似乎我应该使用隐式授权类型，但我不完全理解用户名和密码如何适应该流。有没有人知道我应该使用哪种类型？我所描述的系统是否只能使用 ResourceOwnerPassword 授予类型？
答案 0 :(得分：4)
资源所有者密码授予类型在IdentityServer docs上写了它：
资源所有者密码授予类型允许请求令牌 代表用户通过向令牌发送用户的名称和密码 端点。这就是所谓的“非交互式”身份验证 一般不推荐。
可能存在某些遗留或第一方集成的原因 场景，这种授权类型很有用，但一般 建议使用隐式或混合等交互式流程 而是用于用户身份验证。
（重点是我的）
所有其他流程都涉及重定向：用户点击您网站上的登录信息并重定向到身份服务器登录页面，然后他们在那里输入凭据，然后重定向回原始网页。
例如，使用您的Google帐户登录其他网站也是如此。 Google不希望您将该用户名和密码输入您自己的网站，因为您可以窃取它们，这通常是不鼓励资源所有者密码授予类型的原因。 但是，如果您正在进行第一方集成（即网站是您的网站，并且您信任自己，并且用户在您的网站上输入密码），那么我看不出问题所在。
您应该对其他流/授权类型进行读取（并查看示例）。他们肯定有自己的位置，我不会解雇他们，但如果你正在进行第一方整合，那么正在做的事应该没问题。