现在的情况
我们构建了一个使用受 Azure AD B2C 保护的 Web API 的 Electron 应用程序。身份验证过程如下：
- 用户想登录
- Electron 准备初始 OIDC 请求（包含 oidc 范围的返回类型代码）
b2clogin.comElectron（主线程）使用正确的租户打开系统浏览器- 用户输入凭据并在成功时重定向（使用自定义协议，例如
my-awesome-app://） - Electron 应用程序处理重定向（新实例处理，URL 解析，一切正常）
- 正确解析的信息用于调度最后一个身份验证请求（再次在主进程上）
- 应用程序收到身份验证令牌并且用户已登录
所有这些都可以在不需要嵌入式 Web 视图和处理 localhost 重定向的本地 Web 服务器的情况下工作。至少在我的理解中，我们应该坚持在本机应用程序中使用 OIDC 的最新技术。
问题
上述过程运行良好 - 它只有一个警告：用户输入其凭据的浏览器窗口保持打开状态。据我所知，这是因为浏览器尽职尽责地重定向但从不知道它成功了（即使重定向是由操作系统处理的，浏览器的网络监视器也会显示失败）。
据我检查 GitHub 桌面应用程序、Slack 桌面应用程序以及 Brock Allen 的这个.NET 控制台应用程序示例所知道的，这种行为是可以预料的。Azure AD B2C 的主要问题是身份提供者永远不会离开持有输入凭据的登录表单。
据我所知（我在 Google 和 Microsoft Docs 上花了很多时间）没有明显的方法可以改变这种行为。这些应用程序使用的 IDP 导航到另一个页面，并在登录成功时显示关闭选项卡的消息。我试图在 MSAL 文档中寻找指导——因为它是微软自己的这个用例的库——但他们似乎根本没有考虑自定义协议（显然UWP 甚至不鼓励使用系统浏览器） .
在 Microsoft 实习期间曾尝试为 Electron 提供 MSAL 体验，但这些努力似乎已被放弃。它还会在我们积极尝试避免的同一过程中使用新的电子浏览器窗口。
据我所知，目前“你能得到的最好的东西”是让 IDP 导航到一个窗口，如果用户忘记关闭它，该窗口不能用于提取凭据。
这引出了我的主要问题：是否有可能使用 Azure AD B2C 实现这种行为，还是我们被迫退回到“嵌入式 Web 视图”体验？