我的任务是更新现有的 WPF 应用程序以支持 OIDC 到 Okta 实例。我计划保持此 IdP 独立性，因此我不使用 Okta 的 SSO 库。
桌面应用程序检索授权密钥（它只是一个加密的表单身份验证票），我们使用它来生成用于 API 的令牌。我们希望避免改变目前的工作方式，争取 MVP。
我第一次尝试使用 IdentityModel.OidcClient。使用手动模式，我启动浏览器并按预期从 Okta 取回身份。不幸的是，我的应用程序需要来自我们系统的用户，而不是 OIDC 用户。
此时，我可以将访问令牌发送到服务器，对其进行验证，然后使用我们当前的方法生成一个授权密钥以返回，这样桌面的变化最小。
但在这一点上，桌面甚至自己调用 Okta 是否有意义？
一项提案仍然是启动浏览器，但让我们的网站（支持桌面客户端的网站）向 Okta 发起挑战。该站点也将支持 OIDC 到 Okta。然后该站点将接收回调。在该回调端点中，我们可以验证用户，然后生成授权密钥（我们已在桌面客户端中使用的密钥）。然后重定向到 localhost（就像我们在第一次 stab 中对 OIDC 客户端所做的那样），并通过查询字符串获取授权密钥。
这是错误的方法吗？
不知道在这里做什么。
答案 0 :(得分：0)
我建议尽可能地使架构朝着标准方向发展，并思考如何最好地分离桌面/API/Web 问题：
桌面应用通过系统浏览器管理登录
返回给浏览器的响应是一个（短暂的一次性使用）授权代码，而不是任何形式的访问令牌 - 建议避免将访问令牌直接返回给浏览器，以防止被拦截或可能在浏览器历史记录中包含令牌
桌面应用本身将代码交换为令牌
API 为桌面应用和 Web 应用提供服务，并使用访问令牌作为消息凭据
Web 应用程序的浏览器 UI 可能会使用“前端后端”，其中涉及从身份验证 cookie 转换为访问令牌。这最终会导致浏览器通过与桌面应用相同的 API 获取数据。
通过这种类型的设置，每个组件都以标准方式执行 OAuth，并且易于理解。构建完成后，您的应用将拥有最好的未来选择，并且在安全审查中也表现出色。
系统拥有一个过于专注于网络客户端的“网络后端”是很常见的，而这对于移动/桌面应用程序来说效果不佳。有时需要将 Web 后端重构为新的 API 入口点或微服务，这些入口点或微服务使用访问令牌并对所有类型的客户端等效地工作。不过这可以逐步完成，因此您可能只为您的 MVP 执行第 1 阶段。