1

我想要做的是以下几点:

与 dotnet Core Wep API 通信的 SPA。我想使用社交登录。

我想使用(服务器端)授权代码流。

我倾向于使用 OpenIdDict 来处理 JWT 令牌身份验证。

我设置了 OpenIdDict 的示例项目,特别是 ImplicitFlow 并且我得到了它的工作。但是此示例使用重定向到授权服务器进行实际登录过程。

是否可以让 SPA 也提供这些页面?

似乎这已经完成了,请参阅:https ://github.com/Kukks/openiddict-custom-grants-example

但是我再也无法获得构建概念的证明了。

我想知道的是,Kukks 的概念证明是否仍然是实现这一点的方法,以及我是否以这种方式做正确的事情。还是我在这里打开了一罐蠕虫,我应该只从授权服务器加载一个页面并停止抱怨吗?

4

1 回答 1

2

是否可以让 SPA 也提供这些页面?

不。对于交互式流程(如代码或隐式),授权服务器应该负责身份验证部分,这是保证授权服务器和客户端应用程序之间隔离的唯一方法,它无法“看到”用户凭据. 试图解决这个问题几乎会破坏这些流程的全部目的。

我想知道的是,Kukks 的概念证明是否仍然是实现这一点的方法,以及我是否以这种方式做正确的事情。

如果您拥有客户端应用程序并且如果将您的用户重定向到您的授权服务器(例如使用隐式流程)对您来说是不可接受的,那么是的,您可以考虑使用断言流程。

在这种情况下,JS 应用程序将负责处理社交登录部分(这意味着它将直接向外部社交提供者注册。在经典的隐式流程中,它将是授权服务器)。

还是我在这里打开了一罐蠕虫,我应该只从授权服务器加载一个页面并停止抱怨吗?

如果您决定实施此流程,则在实施外部代码/令牌验证例程时必须非常小心,以避免我们所说的“混淆代理攻击”。

不幸的是,您所指的演示很容易受到攻击,如本票所述:https ://github.com/openiddict/openiddict-samples/issues/13#issuecomment-250903091 。

于 2017-06-09T19:19:13.230 回答