现有桌面应用程序的 OAuth 2.0 工作流程

Question

我的任务是更新现有 WPF 应用程序以支持 OIDC 到 Okta 实例。我计划保持这个 IdP 独立，所以我不使用 Okta 的 SSO 库。

桌面应用程序检索一个授权密钥（这只是一个加密的表单身份验证票），我们使用它来生成用于 API 的令牌。我们希望避免改变目前的工作方式，争取 MVP。

我的第一次尝试是使用IdentityModel.OidcClient。使用手动模式，我启动浏览器并按预期从 Okta 取回身份。不幸的是，我的应用程序需要来自我们系统的用户，而不是 OIDC 用户。

此时，我可以将访问令牌发送到服务器，对其进行验证，然后使用我们当前的方法生成授权密钥以返回，这样桌面的更改就会最小。

但在这一点上，桌面本身甚至调用 Okta 是否有意义？

一项提案仍在启动浏览器，但让我们的网站（支持桌面客户端的网站）向 Okta 发起挑战。该站点也将支持 OIDC 到 Okta。然后该站点将收到回调。在那个回调端点中，我们可以验证用户，然后生成一个授权密钥（我们已经在桌面客户端中使用的那个）。然后重定向到 localhost（就像我们在第一次 stab 中使用 OIDC 客户端一样），并通过查询字符串获取授权密钥。

这是错误的方法吗？

不知道在这里做什么。

Answer 1

我建议尽量将架构引向一个标准方向，并考虑在桌面/API/Web 关注点的最佳分离情况下它的外观：

• 桌面应用通过系统浏览器管理登录

• 返回给浏览器的响应是一个（短暂的一次性使用）授权码，而不是任何形式的访问令牌 - 建议避免将访问令牌直接返回给浏览器，以防止拦截或可能包含令牌浏览器历史

• 桌面应用程序本身将代码交换为令牌

• API 为桌面和 Web 应用程序提供服务，并使用访问令牌作为消息凭据

• Web 应用程序的浏览器 UI 可能会使用“前端的后端”，其中涉及从身份验证 cookie 转换为访问令牌。这最终会导致浏览器通过与桌面应用相同的 API 获取数据。

通过这种类型的设置，每个组件都以标准方式执行 OAuth，并且易于理解。构建完成后，您的应用将拥有最好的未来选择，并且在安全审查方面也表现出色。

系统拥有过于专注于网络客户端的“网络后端”是很常见的，而对于移动/桌面应用程序来说效果不佳。有时有必要将 Web 后端重构为新的 API 入口点或使用访问令牌的微服务，并为所有类型的客户端等效地工作。不过，这可以逐步完成，因此您只能为您的 MVP 做第 1 阶段。