【问题标题】:Centralizing authentication in separate IdentityServer app, but using resource owner password flow在单独的 IdentityServer 应用程序中集中身份验证,但使用资源所有者密码流
【发布时间】:2017-06-30 13:50:24
【问题描述】:

我正在开发两个带有 .NET Core 1.1 REST 后端的 Angular 2 应用程序,并将托管在 Azure 应用服务上。我希望他们共享身份验证信息,这样您就不需要登录两次(实际上是 SSO)。我还想使用 OAuth/OpenID Connect 与第三方提供商集成,但也可以选择创建一个帐户。理想情况下,我希望这两个应用程序在不使用第三方提供商时都使用本机登录名/密码 GUI(不重定向到其他服务)。

为了支持上述所有内容并易于扩展(不维护服务器端会话),我相信我想使用来自 SPA 的 JWT 不记名身份验证。 IdentityServer4 似乎符合要求,我什至可以创建第三个应用程序来托管它,这样我就可以在两个面向公众的应用程序之间共享。资源所有者密码流程将允许我使用本机 GUI。

我遇到的问题是如何处理第三方提供商。如果我使用资源所有者流程,则无法直接从浏览器访问共享的 IdentityServer4 应用程序,因此我似乎需要在两个 SPA 中实现 OAuth/OpenID Connect。避免在两个 SPA 应用程序上实现此逻辑以使用重定向到共享 IdentityServer4 GUI 的其他流程之一的唯一方法是什么?换句话说,使用资源所有者密码流,我仍然可以让 IdentityServer4 以某种方式处理第 3 方身份验证吗?

【问题讨论】:

    标签: angular jwt identityserver4 asp.net-core-webapi azure-web-app-service


    【解决方案1】:

    资源所有者流程不会为您提供 SSO,因为它是一个 RESTful 无浏览器流程(即您可以使用任何 HTTP 客户端来完成)。因此,基本上您将无法通过 IdentityServer4 发出会话。只有像隐式流这样的东西才能为您提供这种能力,原因是隐式流只能通过某种浏览器完成,这意味着 IdentityServer4 可以向浏览器发出会话。当您需要 SSO 时,永远不应将资源所有者视为要使用的流。如果您使用隐式流程,您可能会遇到这里的所有问题,甚至还有大量官方 IdentityServer4 示例代码可以帮助您。

    【讨论】:

    • 如果两个 SPA 应用程序都在同一个域上并且都读/写到同一个 localStorage 位置(并因此共享一个令牌),即使资源所有者流,我也不会有效地拥有 SSO 吗?您甚至可以通过跨域的 iframe 共享 localStorage(例如 github.com/ofirdagan/cross-domain-local-storage
    • 在我上面的评论中,我特别指的是我网站上的用户名/密码,而不是任何第三方提供商。
    猜你喜欢
    • 1970-01-01
    • 2013-11-23
    • 1970-01-01
    • 1970-01-01
    • 2017-10-08
    • 2013-02-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多