在其他主机域上具有Identity Server的oidc-client

Question

让所有浏览器保持快乐似乎是一项艰巨的任务，他们要增加的所有安全性和证书的复杂性。

我有一个SPA（Vuejs），它正在使用oidc-client.js来实现OIDC，并与Identity Server（Identity Server 4）进行通信。 首先要注意的是，如果我在本地主机上同时运行客户端和服务器，则一切正常。

当我将Identity Server部署到我们网络内部的Staging Server时，情况出现了问题。 因此，Idp的主机名现在与SPA的主机名不同（这在生产中是正常的）。

经过大量工作，除IE11（是IE IE）之外，我一切正常。 为了使我到达那里，我不得不做一些事情，例如：

• 解决Chrome的同一站点cookie问题
• 创建自签名证书并将根证书安装在“受信任的证书”中
• 在客户端添加Babel配置代码和Core.js，以使IE在承诺发挥作用时不会引发错误

所以，这是一条漫长的路，但是，我仍然要处理这个问题（请参见动画）：

我只是不太清楚IE为什么要这么做。
无法使用开发工具查看任何信息。
服务器上的日志不包含任何似乎相关的信息。

是否有人在IE中看到过这些“浏览器症状”。

如果人们认为有帮助，愿意提供更多信息（代码，日志等）。只是不想在最初的问题中丢掉所有这些，因为许多人不喜欢那样。

以下是Fiddler的几个屏幕截图。第一个来自 Chrome ： 第二个是用于 IE11 。

由于某种原因，正在使用IE11一遍又一遍地调用Silent Refresh。

我想我可以看到发生了什么，但是不确定如何解决。
似乎有两个对Authorize端点的调用失败，明显丢失了.AspNetCore.Antiforgery cookie。这将导致silent-refresh.html的2次调用。

然后，由于某种原因，对Idp的基本URL有一些GET请求，紧随该请求之后的是对Authorize端点的请求，该端点确实具有{{1} } cookie。

船只将一直保持直行状态，直到下一次调用.AspNetCore.Antiforgery端点，这是下一个周期的开始。

但是，在使用 Chrome 的情况下，用户登录后，对Authorize端点的下一次调用确实包含cookie。

所以，我想这是缺少Cookie的问题。

也许这与我从this post用来解决Chrome Authorize Cookie问题的代码有关吗？

欢呼