IdentityServer4 的 SSO，授权类型为“authorization_code”答案

【问题标题】：SSO for IdentityServer4 with grant type "authorization_code"IdentityServer4 的 SSO，授权类型为“authorization_code”
【发布时间】：2019-01-24 11:04:17
【问题描述】：

我们处于这样一个场景中，我们自己开发的单页应用程序（AngularJS 前端与 https 服务器 API 在后面）打开另一个由我们的合作伙伴在新的浏览器选项卡中开发的 Web 应用程序，而第二个 Web 应用程序需要访问同样由我们开发的 https 服务器 API。

在寻找可能的解决方案之后，我们现在使用 IdentityServer4 创建了一个概念证明，其中第二个 Web 应用程序被配置为具有“authorization_code”授权类型的客户端。当所有应用程序都在同一个域上运行时，第三方应用程序能够访问我们的 https 服务器 API，而不会被提示输入用户 ID 和密码。

在这个概念验证中第二个 Web 应用程序的实现非常类似于bayardw 为帖子提出的解决方案

Identity Server 4 Authorization Code Flow example

我现在的问题是：

当第二个 Web 应用程序不再与我们的应用程序和我们的 https 服务器 API 共享域时，在访问我们的 http 服务器 API 时是否会提示来自第二个 Web 应用程序的调用输入用户名和密码？

【问题讨论】：

标签： oauth-2.0 identityserver4

【解决方案1】：

选择自己通过其他渠道的反馈发布答案：

这归结为 IdP 的会话跟踪。如果使用 cookie 来跟踪 IdP 会话，则行为会受到使用会话 cookie 还是持久性 cookie 的影响。

总的来说，我发现 Robert Broeckelmann 在 medium.com 上有很棒的文章。

【讨论】：

【解决方案2】：

看来，您遗漏了一些重要的事情。
首先，任何 API 都不应该询问用户名和密码。相反，您的应用程序应该在每个请求中放置一个令牌，并且 API 应该验证该令牌。当用户访问您的（或第 3 方）Web 应用程序时，应该询问用户凭据。然后身份提供者创建一个身份令牌（通常保存在 cookie 中并在应用程序中使用）和访问令牌（提供给 API）。
每个令牌都是为在 IdP 中预先注册的特定客户端（应用程序）颁发的。
当您的两个应用程序托管在同一个域中时，可能会共享身份 cookie 和客户端 ID，这是不正确的。
在生产场景中，您必须单独注册应用程序。其余的都应该可以正常工作（如果您按照我在开头简要描述的例程进行操作）。

【讨论】：

感谢 d_f 的回答。很明显，从我简短的问题描述中，您可以假设我的解决方案的各个方面。但是，我不认为我做错了，因为我可以对您描述的解决方案说“检查”。 Robert Broeckelmann 在 medium.com 上对此有很好的帖子，他指出这归结为 IdP 的会话跟踪，我将从那里着手。谢谢。
当然，因为您想知道一些与您所询问的不同的事情，那么是的，没有人能比您回答得更好:) 无论如何，如果您使用 IdSrv 作为您的 IdP，它可能会更简单开始阅读它的文档以研究可能的选项、配置和扩展点。 Robert Broeckelmann 的帖子很棒，但一开始可能太复杂了，他描述的一些内容（例如单点注销选项）在 IdSrv 中没有足够的支持，需要额外的编码。