首页 文章

Identity Server 4和ASP.NET核心标识

提问于
浏览
2

我正在研究的项目包括Web API,单页反应应用程序和移动应用程序 . 每个客户端都需要提供用户名和密码才能访问Web API的受保护部分 . 我已经设置了一个Identity Server 4身份验证服务器,它使用我自己的 IProfileServiceIResourceOwnerPasswordValidator 接口实现,因为我使用的是ASP.NET核心身份 . 这允许Identity Server访问ASP.NET Core Identity UserManagerRoleManagerSignInManagers 以确定提供的用户名和密码是否有效 .

我一直用于所有这些的授权类型是“ResourceOwnerPassword”类型 . 我没有将授权完全集成到单页面应用程序中,但我可以将用户的用户名和密码传递给身份服务器,并生成一个令牌,我可以将其添加到我的API请求的标头中 .

我对Identity Server和相关技术进行了更多的研究,因为我对这一切都是新手 . 似乎不希望使用ResourceOwnerPassword授权类型 . 从我可以看出,似乎我应该使用隐式授权类型,但我不完全理解用户名和密码如何适应该流 . 有没有人知道我应该使用哪种类型?我描述的系统是否只能使用 ResourceOwnerPassword grant类型?

1 回答

  • 4

    资源所有者密码授予类型在IdentityServer文档上写了这个:

    资源所有者密码授予类型允许通过将用户的名称和密码发送到令牌 endpoints 来代表用户请求令牌 . 这就是所谓的“非交互式”身份验证,通常不推荐使用 . 某些遗留或第一方集成方案可能有原因,其中此授权类型很有用,但一般建议使用隐式或混合的交互式流来代替用户身份验证 .

    (重点是我的)

    所有其他流程都涉及重定向:用户单击您网站上的登录信息并重定向到身份服务器登录页面,然后他们在那里输入凭据,然后重定向回原始网页 .

    例如,使用您的Google帐户登录其他网站也是如此 . Google不希望您将该用户名和密码输入您自己的网站,因为您可以窃取它们,这通常是不鼓励资源所有者密码授予类型的原因 . 但是,如果您正在进行第一方集成(即网站是您的,并且您信任自己,并且用户在您的网站上输入密码),那么我看不出问题所在 .

    您应该阅读其他流/授权类型的读取(并查看示例) . 他们肯定有自己的位置,我并没有解雇他们,但如果你正在进行第一方整合,那么正在做的事应该没问题 .

相关问题