0

我正在构建一个 OIDC/OAuth 服务器，它将提供一个 SDK，就像使用 Google 登录一样，成为移动应用程序的 IDP。我们想知道偏离协议以简化流程的风险。

流程是这样的：

  1. 为公司 A 设置了 OIDC 服务器。
  2. 用户使用 A 公司 OIDC SDK 打开 B 公司的应用程序，并输入电子邮件
  3. 发送到电子邮件的 Pin 挑战
  4. 在应用程序中输入密码，屏幕显示同意提示
  5. 好的，应用程序为用户获取 ID + Auth 令牌

应用程序可访问的令牌仅限于应用程序可访问的有限资源集，并且用户可以随时撤销。

这从正常的 PKCE+Auth 代码流中减少了几个步骤，我很难解释为什么这可能对安全性更不利（除了不遵循广泛接受的标准）。

4

2 回答 2

1

创建了围绕安全性的标准，以便可以更轻松地缓解常见的攻击向量。如果您不遵循标准，则必须确保自己满足产品/公司的安全要求。

从这个简单的描述中很难判断您的应用程序是否容易受到攻击。例如，在第 4 点中 - 您如何确保发送 OK 以表示同意的应用程序是首先请求同意的应用程序？您如何确保将身份验证令牌传递到适当的应用程序？这种令牌的 TTL 是多少？你将如何刷新它？当令牌被盗或被拦截等情况下，您有什么计划。如果您遵循 OIDC 或 OAuth 标准及其安全建议，这些都是您将涵盖的所有内容。当您开始发明新的方法来保护自己免受这些威胁时，您最终可能会创建类似于标准的东西。

此外，如果您实施标准流程，您可以更轻松地将自己的 OAuth 服务器更改为市场上可用的产品，如果这成为必需品的话。

于 2021-07-20T10:04:37.843 回答
0

有一个标准化的 OAuth 2.0 扩展，有点类似于您的方法，在 RFC 8628 https://datatracker.ietf.org/doc/html/rfc8628 “OAuth 2.0 Device Authorization Grant”中定义。

关于您的流程的几点说明：

  • 这似乎暗示阅读电子邮件的能力等于用户身份验证，即电子邮件提供者是身份验证提供者；一般情况下可能不适用
  • 该规范警告说，这种方法不应该用于在具有浏览器的移动设备上替换基于浏览器的普通 SSO，这主要是因为失去了灵活性，并且会导致更繁琐的用户体验
  • 我认为没有比 RFC 8628 ( https://datatracker.ietf.org/doc/html/rfc8628#section-5 ) 中提到的那些直接或更多的安全问题，但如前所述，你会在不遵循标准时自行寻找 SDK、应用程序和 OP 的支持
于 2021-07-20T12:21:54.177 回答