我应该避免这种基于令牌的身份验证方案(不是 OAuth)吗?

信息安全 oauth
2021-09-11 10:39:18

我之前处理过 OAuth,但我不太确定我现在使用的 API。我的问题基本上是,这是非常不安全吗?

据我了解,oAuth(大致)执行以下操作:

  1. 服务 X 给了我一个密钥和一个秘密

  2. 我要求用户授予我对服务 X 的访问权限

  3. 我将我的密钥和秘密发送给服务 X 进行检查。服务 X 给了我一个请求令牌,我将它与用户一起发送。

  4. 用户确认他们想让我进入,服务将他们发送回给我,并带有我可以保存在我的数据库中的令牌,并用于代表他们进行服务 API 调用

  5. 在某些时候令牌过期,但服务知道我是谁,所以我可以向他们要求一个新的

但是,我正在处理的 API 是这样工作的(全部通过 https,obv):

  1. 他们给了我一个 API 密钥。

  2. 用户给我他们的用户名和密码

  3. 我将它们与我的 API 密钥一起传输到服务,然后丢弃它们

  4. 他们的服务向我发回了一个令牌,我可以使用它来代表他们进行 API 调用(使用令牌和我的 API 密钥),我将其存储在我的数据库中。

  5. 在某个时候,令牌过期了,我需要获得一个新令牌,因此用户必须重新进行身份验证。

我是否认为该方案与 OAuth 相比的主要弱点如下?

  • 不能保证请求来自我的服务器,所以如果有人闯入我的数据库,他们可以使用我的 API 密钥随意为我的所有用户进行 API 调用,他们可以通过分析我必须在何时发送的 POST验证给定用户
  • 我必须继续使用密码等重新验证用户身份,因为让这些数据四处飘散基本上是很危险的
  • 我有义务首先为用户提供 HTTPS 连接以输入他们的服务密码

这不是生死攸关的事情——它不是人们的银行账户等——但如果有理由相信不会有埃克森瓦尔迪兹的数据泄漏,那就太好了。

感谢您提供任何帮助或建议。

2个回答

这最初在我身上跳出来:“用户给了我他们的用户名和密码”

使用他们的用户名和密码,您可以造成很大的损失。使用 OAuth 可以更轻松地对访问进行精细控制。

我主要担心的是必须处理用户的用户名和密码。我不确定我看到令牌的真正不同之处。OAuth 为您的信息注册到服务提供了额外的能力,因此您可以在将来重新进行身份验证,但最终,如果您的数据库受到损害,那么您的 API 密钥也很有可能也是如此。在这种情况下,令牌在到期之前对攻击者仍然有用,但他们无法在第二个系统下获得新令牌。

从功能上讲,根据密钥存储的工作方式,OAuth 可能会有一点优势,但实际上,主要的有意义的区别只是必须自己转发凭据。