I have a mobile app that requires user login, with user accounts stored on my server. what is the best way to associate a user's account with their Facebook account?
for example, you can login using the Facebook mobile SDK, then send the Facebook user ID to the server. However I'm concerned that this means someone can send someone else's FB user ID (since those are public).
Instead, I send the access token, and retrieve the user ID on my server. This seems a bit inefficient, though, as I'm essentially doing two lookups - once on client for access token, then once on server.
Does it make better sense to do a double lookup, or just send the user ID directly? Or is there a better way?
The only secure way is to send the token to the server and have the server retrieve the user id. This is how services such as stackmob and parse work.
Related
I am using FB js SDK to allow logging in on my platform. A user permits the needed access and I save his ID in my DB. The data is sent to my server via AJAX. Since the login is with FB, I can identify the user only by his ID.
Now, lets say I know someones FB ID and I know he has an account on my platform. In runtime, I can place his ID in the auth request and obtain a legit session of that user. How could that be avoided?
First of all, those are App Scoped IDs, it is very unlikely that someone would know the ID of a user who authorized your App, because it´s not the "real" ID.
That being said, you can (and should) send the User Token to the server and confirm the ID by calling the /me endpoint with that Token. You should also use appsecret_proof for API calls, more information can be found in the docs: https://developers.facebook.com/docs/graph-api/securing-requests
I've got a web app that currently allows users to login via Facebook. This is the only login mechanism at present. I make use of the user id and the users friends to perform certain actions. Now I want to create an api that I can use to create a native mobile app. To do this, I would need to authenticate users against the api. I've looked at this question
Possible approach to secure a Rest API endpoints using Facebook OAuth
but I don't actually have a "user" table as I only pull the facebook info when I need it. In iOS or something similar I could obviously make use of the native facebook sdk and then call my api, passing in the required user id and friend ids etc. however I'm not sure then how I could specifically secure my api so that if a user got hold of another's user_id they could in theory retrieve info via the api or in theory any resource that only specific users should be able to see
I thought about creating an app_id and app_secret for all the separate apps consuming the api. I would then use the appropriate secret to encrypt the data being sent and returned. The api and native app would know the secret and be able to decrypt it and validate that a user can view the requested resource. Does this sounds like a valid approach? In theory only the native apps would then be able to decrypt what is returned from the api. Or should this really be done on a user by user basis as recommended in the linked post?
All of this would be done over https
Thanks
Not familiar with the Facebook API nor iOS so I am speaking completely in theoretical terms.
Could you not:
Ask the user to login with Facebook on the iOS app
Send the login data over a secure channel to your web application to handle the actual processing of the data
Send the iOS app a secure hash for authentication
Use your web application as needed; using the hash for authentication, make HTTPS requests as you would your web application and use the responses from the webserver to populate the iOS app
If you make a user_hash column a complex salted hash like a SHA-256 (or greater) hash, the user_hash will become invalid before anybody is able to guess the hash. You could save the user's Facebook credentials locally on the iOS device and then renew the hash every so often, as to invalidate old hashes and lock out perpetrators (like how a cookie expires). If the user hash somehow becomes invalidated while using the iOS app, the app will send the locally stored credentials and retrieve a new one.
If Apple offers cookies for apps, you could send the hash in a cookie from your webpage and give it a reasonable expiry time (e.g. 1 day). You'd be resending the locally stored Facebook credentials every day and be effectively locking out anybody trying to bruteforce your hashes. Use that instead of trying to implement cookies from scratch (if the iOS API offers that), but as I said, I'm unfamiliar with iOS.
From an SQL standpoint, your webpage would validate a user's Facebook credentials, create a new row with a randomly generated user_hash, expires timestamp, user_id, friends_id, etc. Every user that uses the webpage will have to send the user_hash either from their web-client or the iOS app and will be checked against the database. If the present timestamp exceeds the expires timestamp, the session is ruled invalid and the user cannot operate your application.
Of course, you'd need to encrypt the communication. Do you pass credentials everytime the user loads a page on your web app? Or do you store them in a session?
Hope this helps at least somewhat!
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSHTTPCookieStorage_Class/Reference/Reference.html
I want to enable my users to associate their user account with a Facebook or Twitter and allow them to login on my server with their Facebook/Twitter account instead of using the classic username/password. Basically the same idea as the login in StackOverflow.
My current approach for Facebook:
The client application will perform OAuth and then use their Facebook id to login on my server. Based on this Facebook id, the server will lookup the associated user account and perform login without asking for username/pasword. However just relying on the Facebook id to login is not very safe, as that is the same as using only a username to login instead of username & password.
So to make sure the Facebook id is authentic, the client application will also provide a FBSR (Facebook Signed Request, see: https://developers.facebook.com/docs/facebook-login/using-login-with-games/#checklogin) with the login request.
The server will check two things with this FBSR:
The Facebook id in the request must be the same as the one hidden in the FBSR
Server will recalculate the signature part via the Facebook secret key. This must match with the signature in the FBSR .
Normally the server should perform a check with the Facebook server with the oauth_token to be 100% sure of the users identity. However I need skip this in order to avoid dependency to Facebook server on our server.
I have 2 questions:
1) Is this above approach good enough? Can it be improved (without server-to-server communication)?
2) I want to do the same with a Twitter account, but the their signed request is different then Facebook. It seems the Twitter user id is embedded in the oauth_token, so my approach may work with a little tweak, but I am not sure whether the user id is always part of the oauth_token and cannot get this confirmed after searching the internet.
I think that your approach is good enough and don't see any way to avoid server-to-server communication with a signed request. Bear in mind that, with Facebook Graph Api Version 2, in order to protect the privacy of the user, Facebook will send out not the real user id, but one generated for apps. It will also be possible to enable anonymous login.
I am not sure of what you're trying to do with Twitter, and why you compare the APIs (they're quite different). The Twitter login, also know as Sign in with Twitter, used for any website or mobile app, should work for you too.
A noob question since its my first app to deal with Facebook social sign in. I am developing an app (Flash) which have the ability allow the user to
create normal user account
or
social sign in
The information both store in the same table, but with social sign in off course there is no user password store so i create a account_type which differentiate weather its from the normal user account create or social sign in from Facebook.
Is my appraoch to this correct?
Just wondering what do you need to store in the database in order to authenticate the user, if they come from Facebook social sign in. Because the authentication happen within the Flash application itself rather than going to the server and return result.
So my ulitmate question is what information do i need to store in the database for social sign-in users in order to match with their account and authenticate they are legit user. instead people can just steal email address and access all user's information.
Thanks for any kinda help
The only thing which will identify them uniquely is their Facebook ID. You need to confirm this by requiring them to authenticate, then calling the graph through the ActionScript API to get details of the current user.
Facebook IDs aren't secured in any way (you can look them up with a simple graph call), which is why you need to get the user to authenticate with FB - it's not like ACS, for example, where you set up a relying party and receive a token string that is unique to your application.
After getting the user to authenticate, your code will look something like this:
var auth:FacebookAuthResponse = Facebook.getAuthResponse(); // Gets current authenticated user, or null if no user is authenticated.
var token:String = auth.accessToken; // Access token - only valid for this session, so you can't use this.
var user:String = auth.uid; // Unique identifier of the current authenticated FB user.
I'm trying to implement facebook connect to my website, and i have couple questions.
1: Is it possible to register user in my website using his current facebook email/password.
Let's say user clicks on link Register via facebook and then he have to give me permisions to access his password, email, etc... and after that is done i put that info in my own database and he will be able to login with that account any time he wants without needing to give me permisions any time in the future.
2: If that kind of registration is not possible, what's other solution would be the best for me? Because i need to somehow keep track of that user who logged in with facebook, because he can upload photos, send messages etc.
Anyways, i'm quite new with facebook and similar things, so i'm really lost here, hope some one can help me :)
EDIT Thank you all for wonderful answers it helped me a lot, now all that's left is to read documentation :)
Yes it is, it is possible to get the information of the user. But it is rather complicated, when you have never dealt with it.
First you need to send the user to the following link:
https://m.facebook.com/dialog/oauth?client_id=your-client-id&redirect_uri=xxx&scope=listof-information-you-want
Facebook will then return your client to the uri specified, if the user rejected it will give a reason. If it is not you will get an code in urlencoded format.
This code is needed for the following step, the request of the access token:
https://graph.facebook.com/oauth/access_token?redirect_uri=xxx&client_id=xxx&client_secret=xxx&code=xxxx
This will give back an access token, if the authorization didn't fail.
After that you can ask for the information you want:
https://graph.facebook.com/me?method=GET&metadata=true&format=json&access_token=access_token
This will include a facebook uid, which is unique for all users. Store it and you can discern between a register and login.
This is roughly the process for any oauth2 application.
Facebook will not ask repeatedly for permissions after the user granted them to you. So you can store the access token and reuse it for backend stuff and also use the same procedure you use for register for login.
You can never access the user's password from Facebook even with his/her permission, so the user will always have to authenticate via Facebook and have Facebook pass you the user id of the logged in user once authentication succeeds. You can store all kinds of other data locally, but not enough to authenticate the user yourself.
Once the user is authenticated, you'll have access to the user's Facebook user id via the API, which should be enough to connect all kinds of information to that specific user.
Facebook does not provide access to accounts when passwords are taken from your controls. It provides it own canvas for login information. Therefore you cannot use your first approach to store passwords in your databases. Check this out.
You can however store email addresses once user logins into his account using the facebook sdks. Check this out link for the example of C# SDK sample code.
You can use the Facebook APIs to fetch user email-id, photos, friendslist and other information and then play around accordingly.
You don't get access to the users password - only email if you ask for it.
Best way would be to have a table of users and their Facebook account id's.
If you want to allow users to sign up without Facebook then have a nullable field for their password and facebook id, and also have a field for username - which you could populate from Facebook if they register via that route.