rest - 我应该将 Yodlee 用户密码以纯文本形式存储在数据库中吗？

Question

我正在考虑使用 Yodlee FinApp API 开发应用程序。

他们的 REST 协议(protocol)要求您将用户登录到他们的系统以检索数据。为此，您需要发送登录名和密码。成功的请求会返回一个有效期为 30 分钟的 token 。在 30 分钟过去之前，您必须再次让用户登录以检索新 token 。在我看来，这就是问题所在。

我可以设置一些东西，每次用户登录我的应用程序时，我都会立即将他们的登录信息和密码发送给 Yodlee，并让他们也在那里登录。然后，我不需要将他们的密码以纯文本形式存储在我的数据库中。但是当 30 分钟过去时会发生什么？我实际上并不“知道”他们的密码，因此我无法为他们获取新 token 并要求他们重新登录。如果用户每 30 分钟必须不断地重新登录，那将是一个真正的痛苦。

或者，我可以在他们注册我的应用程序时为他们生成我自己的密码，并将其用于我的应用程序与 Yodlee 的交互。但是后来我将他们的 Yodlee 密码以纯文本形式存储在我的数据库中。假设有人能够访问我的服务器，他们将拥有我的应用程序的凭据以及所有用户的凭据，因此他们将能够模仿我的应用程序的登录过程并获得对用户事务的访问权。这似乎是个坏主意。

这里正确的做法是什么？我正在研究的两种途径似乎都有严重的缺点，但也许我错过了另一个选择？

Answer 1

@aardvarkk- 您打算如何在您的应用程序上对用户进行身份验证？

如果我理解正确，那么您应该将用户凭据存储在您的应用程序中以验证用户并检查他/她是否是新用户。

当您拥有此数据时，您可以在第 30 分钟之前使用相同的数据代表用户再次登录，并且仅当用户仍处于 session 中时，而不是每 30 分钟一次。

我们建议您不要以纯文本形式存储任何用户的凭据。您可以在存储之前对其进行加密，在将其发送给 Yodlee 之前对其进行解密。

此外，对 Yodlee 生产环境的应用程序凭证的访问受到 IP 限制，因此只有来自静态 IP 的请求才能成功连接到 Yodlee。

[更新]对于这种情况:您可以调用 touchConversationCredentials API，它扩展了 session 凭证(即 UserSessionToken)的相对(或不活动)超时有效性。你需要在这传递 userSessionToken。您可以在用户 session 的第 29 分钟之前调用它以将他/她的 session 再延长 30 分钟。但是有 120 分钟的绝对超时，因此在初始 session 创建 120 分钟后它将过期。