3

I'm looking at developing an application using the Yodlee FinApp API.

Their REST protocol requires you to login your users to their system to retrieve data. To do that, you need to send a login and password. A successful request returns you a token that is valid for 30 minutes. Before that 30 minutes elapses, you must log the user in again in order to retrieve a new token. Here's where the problem lies, in my opinion.

I could set something up wherein every time a user logs into my application, I immediately send their login info and password to Yodlee and log them in there as well. Then, I wouldn't need to store their password in my database in plain text. But what happens when 30 minutes elapses? I don't actually "know" their password, so I'm unable to get them a new token and would require them to log in again. It would be a real pain to have users constantly having to log back in every 30 minutes.

Alternatively, I could generate my own password for them when they sign up with my app and use that for my application's interaction with Yodlee. But then I have their Yodlee password stored in my database in plain text. Assuming somebody was able to gain access to my server, they'd have my application's credentials and also all user credentials, so they'd be able to mimic my application's process for logging in and gain access to user transactions. This seems like a bad idea.

What's the correct approach here? It seems like both of the avenues I'm investigating have serious downsides, but maybe I'm missing another option?

aardvarkk
  • 14,955
  • 7
  • 67
  • 96

2 Answers2

1

@aardvarkk- How are you planning to authenticate the user on your application?

If I understand correctly then you should be storing the user credentials in your application to validate the user and also to check if he/she is a new user or not.

When you would be having this data, you can use the same to login again on behalf of user before 30th minute & only when user will still be in session not every 30 mins.

And we would suggest you to not to store any of the user's credentials in plain texts. You could encrypt it before storing and decrypt before sending it to Yodlee.

Also, the access to your application credentials for Yodlee's production environment is IP restricted and hence only request's coming from your static IP can connect successfully to Yodlee.

[UPDATED] For this Case: You can call touchConversationCredentials API which extends the relative (or inactivity) timeout validity of the conversationcredentials i.e. UserSessionToken. You need to pass userSessionToken in this. And you can call this before 29th min of user session to extend his/her session for another 30 mins. But there's an absolute timeout of 120 mins, so after 120 mins of initial session creation it will expire.

Apoorv Awasthi
  • 1,397
  • 1
  • 12
  • 20
  • The problem isn't the *initial* login. I do have credentials for the user -- an MD5 hash of their password that would be compared with what they sent. That's fine the first time they send it. But I don't store their password in plain text. So when 30 minutes elapses, what am I supposed to do? I don't have their password in plaintext, which is what Yodlee requires. All I have is the hash. So I would be forced to ask the user to input their credentials again. No user would be able to use the site for more than 30 minutes with this approach, right? – aardvarkk Apr 21 '14 at 14:31
  • @aardvarkk - I understand how you are going to do _initial_ Login but what about the case when the same user will login again after two days. How do you verify whether he/she is the already registered user to your app? – Apoorv Awasthi Apr 24 '14 at 03:56
  • I will compare a hashed version of their password to what I have in the database. I will not be able to retrieve a plaintext version of their password, though. At the time of their initial login to my site, I *would* be able to pass that information to Yodlee. But after that point, I have no way of knowing their plaintext password and thus could not call `login()` again on Yodlee before 30 minutes elapses. – aardvarkk Apr 24 '14 at 14:17
  • @aardvarkk- I have updated the initial answer. and provided the API(available under Login interface) which should suffice your requirement. Hope this helps. – Apoorv Awasthi May 03 '14 at 19:34
  • That is likely what I'm looking for, thank you. I will experiment with it. – aardvarkk May 12 '14 at 15:05
  • @aardvarkk - Did this help? We are planning to put it over portal also. – Apoorv Awasthi Jun 05 '14 at 18:40
  • I have not tried it -- my developer license expired before the question was answered. I'm currently working on other projects, but it looks like the right idea. – aardvarkk Jun 05 '14 at 18:57
  • If you want please raise a request to Yodlee Sales team and we would like to help you out. – Apoorv Awasthi Jun 05 '14 at 19:03
  • I know this is an old question, but has any of this changed through the years? Systems that need to periodically refresh user information in an unattended fashion are basically forced to store users credentials locally, which is very unsafe. The refresh token mechanism should not have an absolute expiration IMHO or there should be a mechanism to issue a new token based on the previous one, as is commonly done in OAuth. – Pablo Romeo Dec 08 '17 at 17:10
  • @PabloRomeo Yes, there are new ways to extract user's information even without user password. Please look for [Data Extract] (https://developer.yodlee.com/apidocs/index.php#!/dataExtracts). Though, the login mechanism is currently being looked over and there should be something new coming in soon. – Apoorv Awasthi Dec 09 '17 at 20:14
  • @ApoorvAwasthi Thanks! I'll look into dataExtracts – Pablo Romeo Dec 09 '17 at 22:09
0

First off, really try to avoid storing the user's password in plain text. That is just asking for a world of pain if anything goes wrong (e.g., if you get hacked) and can open you up to all sorts of legal trouble. Truly, don't go that way. It would in fact be better off if you never learn their Yodlee credentials at all; you don't want to be them, you just want to interact with the system on their behalf.

REST doesn't really say that much about how systems authenticate to one another; many possibilities are available in general. All you can do is try to connect with whatever credentials you have, and if that fails, bail to the user (well, to client-side code) so that they can give you another token. REST does clearly state how a failure to authenticate should be conveyed, a 401 HTTP response, but that's all really.

Community
  • 1
  • 1
Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
  • 1
    Correct. However, it seems you're only allowed to interact on their behalf for 30min (or 120 at the most). So there's no way to do it periodically (like once a day) without user intervention or storing the yodlee user password. So the api seems to force us to use unsafe practices. OAuth refresh tokens would probably avoid this problem, I believe, if they were to be implemented. – Pablo Romeo Dec 08 '17 at 17:22