我正在考虑使用Yodlee FinApp API开发应用程序。
他们的REST协议要求您将用户登录到他们的系统以检索数据。为此，您需要发送登录名和密码。成功的请求会返回一个有效30分钟的令牌。在此30分钟过去之前，您必须再次登录用户才能检索新令牌。在我看来，这就是问题所在。
我可以设置一些内容，其中每次用户登录我的应用程序时，我立即将他们的登录信息和密码发送给Yodlee并将其登录在那里。然后，我不需要以纯文本格式将密码存储在我的数据库中。但是30分钟过后会发生什么？我实际上并不知道＆＃34;他们的密码，所以我无法让他们获得新的令牌，并要求他们再次登录。让用户经常不得不每30分钟重新登录一次真的很痛苦。
或者，我可以在他们使用我的应用注册时为他们生成我自己的密码，并将其用于我的应用程序与Yodlee的互动。但后来我将他们的Yodlee密码以纯文本形式存储在我的数据库中。假设某人能够访问我的服务器，他们拥有我的应用程序凭据以及所有用户凭据，因此他们能够模仿我的应用程序的登录过程并获得对用户交易的访问权限。这似乎是一个坏主意。
这里有什么正确的方法？似乎我调查的两个途径都有严重的缺点，但也许我错过了另一种选择？
答案 0 :(得分：1)
@ aardvarkk-您打算如何在应用程序上验证用户身份？
如果我理解正确，那么您应该在您的应用程序中存储用户凭据以验证用户，并检查他/她是否是新用户。
如果您有这些数据，您可以在第30分钟之前使用相同的代表用户再次登录。只有当用户仍然不会每30分钟进行一次会话时。
我们建议您不要在普通文本中存储任何用户的凭据。您可以在存储和解密之前对其进行加密，然后再将其发送给Yodlee。
此外，对Yodlee生产环境的应用程序凭据的访问受IP限制，因此只有来自静态IP的请求才能成功连接到Yodlee。
<强> [增订]
对于这个案例：
您可以调用touchConversationCredentials API来扩展会话密钥的相对（或不活动）超时有效性，即UserSessionToken。您需要在此传递userSessionToken。你可以在用户会话的第29分钟之前调用它来将他/她的会话延长30分钟。但是有120分钟的绝对超时，因此在初始会话创建120分钟后它将过期。
答案 1 :(得分：0)
首先， 确实尽量避免以纯文本格式存储用户密码 。如果出现任何问题（例如，如果你被黑客攻击），这只是要求一个痛苦的世界，并且可以让你面对各种各样的法律问题。真的，不要那样走。 事实上，如果你根本不学习他们的Yodlee证书，那将会更好;你不想 他们，你只想代表他们与系统进行互动。
REST并没有真正说明系统如何相互验证;一般来说有很多可能性。您所能做的就是尝试连接您拥有的任何凭据，如果失败，请保释给用户（以及客户端代码），以便他们可以为您提供另一个令牌。 REST确实清楚地说明了如何传达验证失败，401 HTTP response，但这都是真的。