MrSwitch / hello.js

A Javascript RESTFUL API library for connecting with OAuth2 services, such as Google+ API, Facebook Graph and Windows Live Connect
https://adodson.com/hello.js/
MIT License
4.64k stars 547 forks source link

doubt: how to keep my webapp safe? #22

Open cesardevera opened 10 years ago

cesardevera commented 10 years ago

hi,

I'm impressed and enthusiastic about hello.js, but there is something I still couldn't figure out: if the login happens client-side, what can I do in my webapp to send back to my server the authenticated login name in a safe way?

I mean, for example, if I authenticate my user on facebook client-side, would I be supposed to redirect or post the user page to something like http://mysite/authenticated?where=facebook&username=myusername

that approach would allow anybody to just type that url and be considered authenticated with that login.

I believe you have a pretty obvious solution to this problem, but I can't think on anything now.

do you have any suggestion?

MrSwitch commented 10 years ago

Yeah that would be open to hacks. You'll need to make a server-to-server request with the users access_token, e.g. GET request to https://graph.facebook.com/me?access_token=123 would return the users profile with a Facebook access token.

You could get the token to your server by sending it after the client authentication flow OR by using the OAuth2 bearer approach.

Unfortunately i've not addressed serverside requests with HelloJS other than authorization. There are other solutions like Passport and EveryAuth which focus on serverside auth, pumping the access_token back to the client would be awesome, but as yet unbeknownst to me.

Glad you like the project :) Its still maturing so I appreciate it!

On 10 Nov 2013 11:48, "cesardevera" notifications@github.com wrote:

hi,

I'm impressed and enthusiastic about hello.js, but there is something I still couldn't figure out: if the login happens client-side, what can I do in my webapp to send back to my server the authenticated login name in a safe way?

I mean, for example, if I authenticate my user on facebook client-side, would I be supposed to redirect or post the user page to something like http://mysite/authenticated?where=facebook&username=myusername

that approach would allow anybody to just type that url and be considered authenticated with that login.

I believe you have a pretty obvious solution to this problem, but I can't think on anything now.

do you have any suggestion?

— Reply to this email directly or view it on GitHubhttps://github.com/MrSwitch/hello.js/issues/22 .

carolinebeltran commented 10 years ago

I am planning to have a profile created by my app based on the Google or Facebook login results and I am concerned with security since authentication will happen between the Google/Facebook and the client, thus leaving my server out of the loop. I'm mainly concerned with:

1) Will people with existing account profiles on my system be subject to impersonation by a hacker?

2) Will hackers be able to create 'bogus' accounts on my system by faking Google & Facebook authentications?

Thank you kindly

UPDATE - after learning some more, I am thinking that there should not be any issues regarding my concerns above.

sjungwirth commented 10 years ago

Hi, what I have done is pass the access_token to the back end over https. From the backend you need to fetch the user's profile information again directly from the network to verify authenticity.

coryarmbrecht commented 9 years ago

It seems that I'm looking to integrate hello.js and passport (jwt). Maybe this question stems from me still learning hello.js. Would I use the returned server -> server call with the authenticated access_token as the userId in a users database? Are tokens for client / server services authentication the same?

I'm trying to figure out if I should be splitting / mirroring calls from service -> client -> server, or just do everything through the server altogether... Based on this thread, I'm curious if I could use hello.js for client login, and then have it give the server the JWT for the rest of the api calls.

sjungwirth commented 9 years ago

Lots of questions here, I'll try to address each separately...

"Would I use the returned server -> server call with the authenticated access_token as the userId in a users database?"

The access token is valid for only a certain lifetime and can be revoked, so I would definitely not use it as a userId.

"Are tokens for client / server services authentication the same?"

Yes, the access token can be used to make api calls from the client (browser) or from your server.

Based on this thread, I'm curious if I could use hello.js for client login, and then have it give the server the JWT for the rest of the api calls.

I am not using JWT but something similar, and this is basically how I am using hello.js, and the only reason to do it that way is that I don't "trust" the client to give me the right info, I want to get it directly from the service in question.

immigrationanytime commented 9 years ago

Hi. I am using hello.js inside a Phonegap app. I cannot find any security or hacking issues with this type of scenario. Am I correct to think so? Any insight is appreciated.

coryarmbrecht commented 9 years ago

Awesome, @sjungwirth! Thanks for the response.

I thought about my User ID question some more, and came to the same conclusion. I was sort of thinking about what to do before I get my User's info, like username, name, etc.

Good to know about the token being the same. Looks like this is the route I'm going to go for now. Thanks again!

MrSwitch commented 9 years ago

@immigrationanytime there is potential for a phonegap app to sign the user in with another client_id not registered for that app. Since there is no same-origin check in phonegap - instead it monitors the InAppBrowser address location for the token.

This will only be a problem when you are reaching your limit on API requests. Or your app has been granted special user privileges by the provider and you dont want another app to exploit them.

In any case, I am not aware of a way to prevent this in OAuth2 flow. Providers can typically mitigate against this by affirming the app name for the registered client_id, but doubtless this will catch some users out. At the end of the day its still the users choice.

jonnyquizzical commented 9 years ago

I've been using hello.js to create social logins and publishing features for every social application imaginable on a web application, so its been very helpful to me, but just as the poster I'm having problems trying to secure the login procedure for the web.

I cannot find a single python or php script available that can be used to verify token's across all networks, and find it daunting to have to write one for each one, so if anyone has one that would be very helpful.

Notwithstanding that, it does occur to me that by passing all the tokens through ajax to the server and using http://php.net/manual/en/book.v8js.php it may be possible to run existing hello.js functions to verify the session. However, I can't find the function that would be used to do it, as obviously getAuthResponse() doesn't accept arguments. Is there any possible method, or am I on the wrong track here?

MrSwitch commented 9 years ago

Hi @jonnyquizzical Contrary to resending the tokens as i previously suggested. I believe it is best to recreate the OAuth Proxy service in your apps language. You can then define hellojs to use "explicit" grant, that way all your logins will go via your app, which can in turn catch the tokens at their point of creation, assigning those to the users session. However this does require understanding how the messaging between HelloJS and the OAuth Proxy works as you will need to recreate it verbatim.

An alternative might be to use an existing OAuth library for PHP or Python. If you an get an access_token via a thirdparty library you could retro-fit it to HelloJS, i.e...

hello.utils.store( 'facebook', {
    access_token : 'token',
    expires : '1212212121'
});

If you would prefer to recreate the OAuth-Proxy that would certainly help alot of others in the same boat as you.