Hi I'm working with yodlee API to scrape data from customers bank accounts.
For this, Yodlee needs customers Internet Banking Credentials. The examples I've seen request the user's credentials, pass them through your own server to Yodlee. Ideally I would like the user to authenticate with Yodlee and never give myself access to their credentials. This is what I'm thinking of:
1) My server creates a new cobrand session with yodlee using cobrandLogin and cobrandPassword
2) cobSessionToken is sent to the users browser
3) user logs in passing their IB username and password and the cobSessionToken to yodlee.
Is this setup secure? Is there any risk in exposing CobSessionToken to clients?
This setup is highly secure. However we recommend you to not to expose the cobsession token to the user, instead make the users to use your cobrand context in the backend and generate their user context.
Hope this helps.
Regards,
Krithik
Related
For example if i have build a mobile application and using the nodejs REST api for accessing the backend.
I want to restrict the access of the application with same login credentials on a maximum of two devices.
For example me and my friend can have have access to the application with same login credentials but a third friend must not be allowed to have access to the account with same login credentials.
Can it be implemented with some kind of token. Can anyone please help me in understanding the concept to implement this.
Posting as an answer, since it does appear to be a solution.
It can be implemented with a token, but I think it's important here to maintain sessions. Also, you need to keep track of who is connected to what account, and from what device. You'll definitely need unique identifiers, and to know how many logins the account is already utilizing. If a user logs out, remove that device from the list until they login again. Read up on session management. I have had good success using PassportJS for stuff like this :)
I am trying a post-call to generate an access token using the client username and password. I would like to know how we can achieve this through Node Js Code.
Generally speaking, access_token are rattached to the OAuth2 authentication framework, which doesn't require the application owner (you) to have access to one of your user email/password. This is a more secure approach that is broadly adopted.
The way OAuth2 works on the Google Calendar API is a 3-parties (or 3-legged) authorization. Let's take the example of a user that browses your website and want to sign-in using its Google Account. The steps to authenticate him are the following:
The user clicks on "Sign-in with Google"
The application owner (you) performs a request to Google saying that a user wants to connect (that's the OAuth consent screen)
Google replies by giving you a URL (authorizationUrl) where to redirect the user
On that URL, the user is prompted with several information about your application and can grant access.
When the user has granted access, Google will redirect the user to your application success page (callbackUrl) with a unique code.
Using that code, the application can retrieve an access_token, which temporarly lets your application performs requests on behalf of a user.
These steps are a rapid overview of the OAuth-flow, also known as the OAuth dance. To make POST requests to the Google Calendar API, you will have to perform that OAuth dance for every single of your users.
Implementing that flow can be tricky. Fortunately, Google gives very helpful documentation on that. If you don't want to bother, you can also use API-tools (like Pizzly) that takes care of that for you.
I'm learning Node, doing authentication stuff at the moment with passport.
Say my server has 2 pages, a public home page with various login options, then a super-secret page(and perhaps more) that is only accessible after authenticating.
If I'm only going to be using 3rd party strategies, is there any reason to have a database?
I know that you'd obviously need one for local user's id and pass, but if the server exclusively relies on 3rd party authentication, would session persistence be enough things to work? Or are there still various things that you would need to save for some reason (apart from logging) ?
Could you do without a database, sure... but in this case what is the point in authenticating at all? All you would be proving is that the user has a Google account which anyone can set up for free in a matter of minutes.
If your content is super secret then chances are you want to have a database of users (email addresses and the like) that have permission to see the content. By authenticating through OAuth you will be given an access token that will allow you to fetch the authenticated users email address. This can then be looked up against your user table to see if the user is registered and if your app enforces it, check whether the user has access to the page requested.
OAuth is proving that this person is the owner of the Google/Facebook/Twitter/Github Account. You can use this knowledge to sign someone in against a database of "local accounts" based on email used at sign up, assuming you validate the email on sign up locally.
I have a web site and every client has his own account. When clients create new articles, titles should go to their own twitter accounts.
The question is how to make it in background? I can ask user for twitter login/password - and save this data in my database. But the problem is with security: password will be stored unencrypted.
Does twitter have better way to organize this flow?
thank you
p.s.
to make it clear - background sending is must - as some clients use API to access my services
OAuth is the solution to your problem. OAuth is supported by Twitter.
By using OAuth, each of your users may authorize you to post tweets on their behalf. You will get a token for each user. You must store this token in your database, but you will not need the end users username or password.
I'm working on a web application which involves connecting to Gmail on behalf of a user to check for new messages. Is there a way to securely store the user's credentials so that they can still be recovered for the login, or is there some way to obtain a token for Gmail to use in connections?
EDIT: The application is meant to be used mostly with mobile users, so they won't be logging into the site frequently. Thus, storing information in a cookie isn't viable.
If you logged into GMail's web interface it gives you a token in the form of a cookie. If yYou could use that token and the web interface then you could access their email without storing their credentials. Of course that isn't IMAP access, and it expires (as a good token should).
Alternatively you could encrypt their credentials with a value you store as a cookie on their computer. Then when they access your site you can check their mail without ever storing the encrypted credentials with the key to decrypt it.
Neither is an ideal solution, but hopefully they get you moving in the right direction.