我要做的是以下内容：
与dotnet Core Wep API通信的SPA。 我想使用社交登录。
我想使用（服务器端）授权代码流。
我倾向于OpenIdDict来处理JWT令牌认证。
我设置了OpenIdDict的示例项目，特别是ImplicitFlow，我让它工作了。 但是此示例使用重定向到授权服务器进行实际登录过程。
是否可以将SPA这些页面服务好？
以前似乎已经完成，请参阅：https://github.com/Kukks/openiddict-custom-grants-example
但是我不能再建立这个概念证据了。
我想知道的是，Kukks概念证据是否仍然是实现这一目标的方式，以及我是否通过这种方式做正确的事情。或者我在这里打开一罐蠕虫，我是否应该从授权服务器加载页面停止抱怨？
答案 0 :(得分：2)
是否可以将SPA这些页面服务好？
没有。对于交互式流程（如代码或隐式），授权服务器应该负责身份验证部分，这是保证授权服务器和客户端应用程序之间隔离的唯一方法，无法“查看”用户凭据。试图解决这个问题几乎会破坏这些流程的整个目的。
我想知道的是，Kukks的概念证明是否仍然是实现这一目标的方式，以及我是否通过这种方式做正确的事情。
如果您拥有客户端应用程序并且将用户重定向到授权服务器（例如使用隐式流程）对您来说是不可接受的，那么您可以考虑使用断言流程。
在这种情况下，JS应用程序将负责处理社交登录部分（这意味着它将直接向外部社交提供者注册。在经典隐式流程中，它将是授权服务器）。
或者我在这里打开一堆蠕虫，我是否应该从授权服务器加载页面停止抱怨？
如果您决定实施此流程，则在实施外部代码/令牌验证例程时必须非常小心，以避免我们称之为“混乱的副攻击”。
您所指的演示很遗憾，如本票中所述：https://github.com/openiddict/openiddict-samples/issues/13#issuecomment-250903091。