I am currently developing an app that will use the FB SDK (for the first time) to log a user into the app. The flow is typical, I assume. User taps "log in with facebook", facebook graph authenticates, then we do a call to our api and log the user in via their facebook email (only) we have on file.
However, whats freaking me out here is, theoretically if some knew our api_token, and knew that calling a POST to a login url with only a valid existing email to log them in, isn't that a security issue since they could actually log in as someone else. Am I over thinking this? Understandably, they'd have to know every aspect of the api to do any damage. But still, I'm not feeling comfortable with this flow. Am I missing something?
This shouldn't be something you have to worry about. Facebook first protects you by having the requirement for the user to be logged into Facebook. Next, the user's UID(readily available to anyone) and your API Key isn't enough. They'd still need your API Secret Key (which if someone has is a bad thing) to sign requests as you.
What you're really using is OAuth (though Devise, through OmniAuth). I'm not an expert but you can read more here: http://hueniverse.com/oauth/guide/security/
When a user registers via OAuth, you aren't going to have a password set for them, and that's not a huge deal as they have to also first log into Facebook. It might be a good idea though to ask them to set a password if they ever edit their account, that also means they can sign in the old fashion way if they desire/delete Facebook/etc.
Related
I have Oath working with Facebook, Google, and Twitter; however, I am having an issue with the latter where it uses an "authorization" URL each time rather than "authentication". The result is that the user is asked to authorize my app each time. With both Google and FB once the app is authorized they are not asked again when they log in. It is aware behind the scenes if the user is logged into one of those services and if so (and they already authorized my app) it logs them immediately into my app. With Twitter it will take them to an authorization screen each time.
I know this is due to the flow I have with Twitter which which says: redirect_url = auth.get_authorization_url() followed by a self.redirect(redirect_url)
The key above is "authorization" which is unaware of the user's acceptance of my app previously. In Twitter I know there is a checkbox to "allow this application to be used to sign in with Twitter". This is checked. What I am not able to find is the correct path with Tweepy that checks whether the user is already logged into Twitter and has already authorized my app.
I do save the tokens that Twitter sent back with the user at first authorization, however, I have no idea who the user is until they login so I cannot try to use these tokens for this initial part of the exercise. I should note that I don't have to use the tokens from Google or FB either at this stage.
Can Tweepy be used in the manner described above or do I need to do something else?
Thanks!
Fortunately, there is a very simple solution. When calling api.get_authorization_url, simply specify signin_with_twitter=True as a keyword argument. Your call should look like this:
api.get_authorization_url(signin_with_twitter=True)
This causes Tweepy to use the 'authenticationendpoint you mentioned, instead of theauthorization` endpoint.
I am using the code that gets implemented in a new MVC Project for user to Log into Google,Yahoo, Etc.. I have it all working but what I notice is when I try to log-in with Yahoo, there might be another user (my brother-in-law) logged into Yahoo on my machine, so when I try to log-in, it tries to register him. That is annoying, so I want it to force the user to re-enter their username/password on Yahoo (google, etc). Is that possible? This seems like a security flaw also. If I was in my app and then logged out, but did not log out of Yahoo, Google,etc.. anyone could come along and log in to my app. That hole is so wide and obvious it tells me I am probably doing something wrong, because they would not have designed it that way. I am thinking I need to destroy some cookie or token on my site when the sessions ends or I log out..
I'm currently implementing an Oauth consumer service which is going to use Soundcloud as an Oauth service provider as well. But I'm having the following issue with it: Taking Facebook or Twitter example, you go there, you sign in, you fill up the permission form, and you are redirected back to your app. If you go there a second time, and given you are already sign in, you basically skip all steps and are redirected back instantly. That means, Facebook recognized that you already gave permission to that 3rd party service, so it doesn't ask your permission constantly.
And that's what's happening when I use Soundcloud. Basically everytime I redirected the user to the Soundcloud Oauth connect endpoint, the permission form always shows up, even though I already gave permission to that 3rd party service previously. I'm forced to press "connect" every single time, which is a drag from the user perspective (how many times can you give permission to the same entity). My question is: is there a parameter I can use to make soundcloud recognize/validate the previous permission from the user account to that specific 3rd party service? Or is this Soundcloud Oauth design implementation and we have to live with it?
Edit:
Maybe this wasn't clear, but each time I press "connect" in soundcloud, a new access token is being generated and delivered. Since my app uses this access token to identify its users, it doesn't work very well for me that the access token is getting updated everytime I want to log in, making me effectively "sign up" everytime. To sum it up, I want to get the previously attributed token to my account, so I can look up in my database, identify it and log him in.
I'm also looking for a solution which doesn't involve storing state in the client that might get cleaned up.
What you can do is store the user's oauth token in local storage and reuse it in future sessions. That's what happens on soundcloud.com.
A longer explanation:
When you use the Connect flow, the user is authenticated by SoundCloud (either by using username/password, Facebook Connect, or an already-existing session on soundcloud.com), and then when it is successful, your app is given an oauth token for that user. This is passed to the callback page which is registered for your app.
That token is the only piece of information needed to have the user be "logged in". Unless the token expires (by time, or by the user manually revoking it), then you can reuse that in future sessions.
I think I'm a bit confused about your application's design: where and how is the oauth token being used? I think that instead of using the token as an identifier, perhaps the user's permalink might be better? If you have the oauth token, you can find out the permalink by querying api.soundcloud.com/me.
I have a facebook application that the user has authorized. I want to re-authenticate when their token has expired. The problem is that when the user is already logged in to Facebook, and they have already authorized the application, facebook just redirects back to the redirect_url. I don't want this behavior as the user may have multiple facebook accounts and the one they're logged in to may not be the correct one.
The initial facebook authorization happens via server side authentication.
I want to either:
pick which one [account] to authenticate with (this is ideal) or
force them to re-authenticate their facebook credentials
I would like to avoid using the javascript sdk to force logout then re-login in if possible. I would like to keep everything server side for maintenance reasons.
You can configure omniauth-facebook to force reauthentication by setting auth_type to reauthenticate.
I don't know how to force to re-authenticate users. ( that would be the better solution ) But It's the first time I hear someone who wants the token expires faster. (Token last 2 hours, https://developers.facebook.com/blog/post/2011/05/13/how-to--handle-expired-access-tokens/ ).
Your use case it's really unusual:
"the user may have multiple facebook accounts and the one they're logged in to may not be the correct one"
Who has multiple Facebook accounts?
Maybe if your are a developer, you will need an extra account, but it's better to use this:
https://developers.facebook.com/docs/test_users/
Regards
Ivangrx
force them to re-authenticate their facebook credentials
The OAuth dialog offers a method for Re-Authentication – but I’m not quite sure if that fits your needs, so you’ll have to give it a try.
Ok this is something weird. I got authlogic-oid installed in my rails app today. Everything works perfectly fine but for one small nuisance.
This is what i did:
I first register with my google openid. Successful login, redirection and my email, along with my correct openid is stored in my database. I am happy that everything worked fine!
Now when i logout, my rails app as usual destroys the session and redirects me back to my root url where i can login again. Now if i try to login it still remembers my last login id. Not a big issue as i can always "Sign in as a different user" but i am wondering if there is anyway to not only logout from my app but also logout from google.
I noticed the same with stack overflow's openid authentication system.
Why am i so bothered about this, you may ask. But is it not a bad idea if your web apps end user, who happens to be in a cyber cafe, thinks he has logged out from your app and hence from his google account only to realize later that his google account had got hacked by some unworthy loser who just happened to notice that the one before him had not logged out from google and say.. changed his password!!
Should i be paranoid? Isn't this a major security lapse while implementing the openid spec? Probably today someone can give me a workaround for this issue and the question is solved for me. But what about the others who have implemented openid in their apps and not implemented a workaround?
If this is such a big issue to you, do not use OpenID, or display a DHTML popup after a successful log out reminding the users that their session is still valid on their OpenID provider.
As for Google's OpenID, what you can probably do is redirect users through the following URL after
http://www.google.com/accounts/ClearSID?continue=http%3A%2F%2Fwww.google.com%2Faccounts%2FLogout%3Fcontinue%3Dhttp%3A%2F%2Fwww.google.com%2F
Afaik, there is no way you can log the user out of their account in another system. Your app is supposed to be responsible only for it's own business. As a user, I'd be very surprised if a website using openid could log me out of my google account.
Yes, there is a scenario that a user can assume that they are logged out of google because they logged out on your site but that would (and should) be their own fault.