我实施 OAuth/OpenId 有多差？

Posted 2023-03-27

【中文标题】我实施 OAuth/OpenId 有多差？

【英文标题】：How poorly have I implemented OAuth/OpenId?

【发布时间】：2021-10-08 02:53:59

【问题描述】：

我不禁认为我在实现 Open ID 方面略有错误，但我也找不到为什么我以我的方式完成的实现是不好的。

场景：

网站 - 在更新为使用 OWIN 之前使用了表单身份验证。表单身份验证已被删除。

网站现在支持 OpenId 到 Okta。我们正在为我们的一家大公司实施此操作，以方便他们的登录。这是实用的。

我用于站点的方法模拟了 Microsoft 的登录方式。在电子邮件域检测中，我们将用户重定向到其域的登录页面。在这种情况下，奥克塔。我们收到回调，并在我们现有的数据中查找用户，并根据我们现有的数据生成一个 cookie（如果他们没有，则创建一个新的用户帐户）。 本质上，只是使用 Okta 来确认他们是有效用户，然后我们使用我们的用户数据登录他们。我们预计其他公司也会这样做。

问题：

我有一个桌面 (WPF) 客户端，需要登录我们的网站。这与使用我们多年前构建的身份验证密钥/令牌系统已经存在的 API 对话。理想情况下，我们会做类似的事情。使用 Okta 验证用户是该系统的用户，然后生成可用于这些 API 的令牌。

这里是我不确定我是否做得适当的地方。

桌面客户端使用用户输入的电子邮件域调用我们网站上的 API 端点。我们验证用户的域是否允许使用 SSO，如果允许，我们会发回一个质询端点供客户端调用。然后桌面客户端调用此质询端点以启动用户默认浏览器。

这个质询端点是我们网站上的一个端点，它本质上会触发对 IdP 的质询。登录后，会在我们的网站上调用回调，以处理身份验证响应。我们验证用户的帐户是否有效，并从响应中获取刷新令牌。使用刷新令牌和用户标识符，然后使用 localhost:randomPort 将此数据发送回桌面客户端，以便客户端可以使用刷新令牌和标识符。 （请注意，在将刷新令牌和标识符返回给客户端之前，我会对其进行加密）

然后将此刷新令牌连同它们的标识符一起发布到我们的网站（这样我们就可以识别我们应该调用的 IdP），然后使用 OIDC 客户端来验证刷新令牌是否仍然有效。如果刷新令牌仍然有效，我们生成一个应用令牌并返回它。

这是如何实现的，我没有看到一个明显的问题吗？我怎样才能做到这一点？

【参考方案1】：

您似乎缺少您拥有的授权服务器 (AS) 的角色，该角色无法管理与其他系统的连接以及向您的应用颁发令牌。

你似乎有一些很好的分离并且在很多事情上做得很好——例如你使用的是你自己的令牌而不是外国的 Okta 令牌。主要问题可能是系统的发展。

首选行为

AS 应该产生更简单的代码和更容易扩展的系统：

您可以快速添加新的身份验证方法 这应该只涉及向您的 AS 添加一个连接（例如 Okta） 这样做需要对 UI 和 API 进行零代码更改 您的 UI 只使用标准 OpenID Connect 流并调用 AS 端点，而不管使用何种身份验证方法 您的 API 仅验证 AS 颁发的令牌，然后授权请求，而不管使用何种身份验证方法

在 AS 中需要一些脚本，但通常很小。

特点

关于 AS 应该为您做什么，请浏览Curity Concepts Pages。我在那里工作，我们尝试撰写有关 OAuth 的科学以及软件公司需要的常见可扩展性功能的文章。

选择你的时刻

不过，集成 AS 并克服所有阻塞问题是一个循序渐进的过程，并且涉及到学习。因此，它需要选择您的时刻、高峰并获得利益相关者的支持。

主要目标应该始终是应用中的简单标准代码，即易于扩展。 OAuth 和授权服务器为您提供有助于此的设计模式。

【讨论】：

谢谢！我很高兴读到。这绝对是我们计划要做的事情，但目前我们正在尝试启动并运行某些东西，而无需建立另一台服务器。