使用 WinForms 应用程序的 OAuth/OIDC SSO 的最佳实践？答案

【问题标题】：Best practice for OAuth/OIDC SSO with a WinForms app?使用 WinForms 应用程序的 OAuth/OIDC SSO 的最佳实践？
【发布时间】：2021-12-08 15:30:04
【问题描述】：

我们正在向当前使用 Windows 集成身份验证进行单点登录的应用程序添加现代身份验证 (OAuth/OIDC)。用户登录到 Windows 工作站，许多应用程序可以使用这些凭据，并通过 Kerberos 透明地进行身份验证。

我们的应用程序是一个基于 .net Web 服务的应用程序，我们为使用浏览器的用户提供了一个客户端，并在 WinForms 中提供了一个桌面客户端。浏览器场景没有问题，因为身份提供者将信息存储在浏览器中，这些信息可以以类似于 WIA (IWA) 的方式跨应用程序重用，但我们不确定处理 WinForms 桌面应用程序案例的最佳方式。目前，WinForms 应用程序打开一个浏览器窗口以使用典型的基于浏览器的方法进行身份验证。来自身份提供者的详细信息通过浏览器使用重定向和基于自定义协议的 URL 传递回 WinForms 应用程序。

这一切都很好，但用户体验不是很严格，对于用户已经登录的情况，要求他们在浏览器窗口中按下一个按钮，因为当前基于 Chromium 的浏览器似乎不愿意进行重定向没有最近的用户交互。

有没有更好的办法？

【问题讨论】：

标签： winforms oauth-2.0 single-sign-on openid-connect

【解决方案1】：

RFC8252 的标准选项如您所描述：

通过系统浏览器登录
使用基于环回或私有方案的 URL

我有几个blog posts 关于这个，这是一个棘手的流程。这些帖子链接到您可以运行的代码示例，这些示例探索了一些 UX。您可能会发现环回 URL 避免了单击按钮的需要，尽管我个人认为基于私有方案的 URL 更简洁。

您可以做一些用户体验方面的事情，例如插页式网页，以更好地控制断开连接的浏览器中发生的事情。我看到公司在桌面登录后重定向到他们自己的网站，以改善用户体验。

从长远来看，我希望它会被 API Driven OAuth Flows 取代，这样您就无需离开应用程序。目前，您可能不得不忍受一些 UX 限制，但从安全角度来看，这是正确的流程。

【讨论】：