捷径 OAuth/OIDC 的风险？

Question

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

流程是这样的：

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

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

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

Answer 1

有一个标准化的 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 的支持不符合标准

Answer 2

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

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

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