0

Let's say I have this application developed for Android which needs to use a Facebook (or Twitter or Google or all of them) based authentication so it can access this private API I've developed with nodejs' Express for example (could be any other platform too). I've read this answer here that gave me a hint on how to associate my authentication model with my user model (and another one here that made me realize those two parts are different), Facebook authenticates and I use some information they provide to create an "identity" for this user, but what exactly is this information that will create a link between the user and the identity? no abstract terms please, do I need to use and send either the access token or the Facebook user id? or would I just send the access token and let the server get the user id?

Regarding new requests after this user has been authenticated, I've read about API keys of some sort, which are basically some random strings that I should add to my identities (or users? this part confuses me) entities, and they should be securely stored in the mobile device as a mechanism to authenticate further requests, but how do I securely get this random string to the device in the first place? am I misunderstanding the way API keys work? are Facebook authentication and API keys mutually exclusive? if so, what would I use for further requests just using a provider for my authentication? it seems illogical to pass the access code in every request, even more so passing the user id.

The focus of this question is for me model a solid strategy for managing this authentication-user-identity behavior, would love any insights on how has this been done before since the material I've found in SO and the web has been very lacking, often referring just to server side implementations or just authentication answers, not addressing the issue of further requests.

Community
  • 1
  • 1
Eduardo Naveda
  • 1,880
  • 3
  • 15
  • 30

1 Answers1

1

The Facebook/User ID is there to identify the (returning) User. Keep in mind that you only get an "App Scoped ID", not the "real" ID - it will be unique in the App, but different in another one. See changelog: https://developers.facebook.com/docs/apps/changelog

Access Tokens are there to make calls to the Graph API. There are 3 different Tokens (App Token, User Token, Page Token), you can read more about them in those articles:

You can store Access Tokens for later, but in most cases you don´t need to store them - only if you need to access the API while the User is not using your App.

In general, App Tokens can be used to request public stuff and to change App settings. User Tokens can be used to request (or post) User stuff and Page Tokens can be used to request insights of a Facebook Page and other things.

If you want to deal with Access Tokens on your own, make sure to activate appsecret_proof in the settings. I suggest reading this article about securing API calls: https://developers.facebook.com/docs/graph-api/securing-requests

andyrandy
  • 72,880
  • 8
  • 113
  • 130
  • so it should be safe to send the user ID from the mobile device to the API for user association? have you any insight regarding my questions about API keys? – Eduardo Naveda Oct 17 '14 at 12:04
  • if you mean the key hash, maybe this thread can help: http://stackoverflow.com/questions/4388992/key-hash-for-android-facebook-app – andyrandy Oct 17 '14 at 12:20
  • and yes, it is definitely safe to send the user id around. you only need to be careful with access tokens (although they get handled by the sdks anyway) - and use the app SECRET on the server only, it´s called secret for a reason :) – andyrandy Oct 17 '14 at 12:21
  • i´ve added some more information, i forgot the very important appsecret_proof possibility :) – andyrandy Oct 17 '14 at 12:24
  • No, I didn't mean facebook key hashes, I'm referring to what should my application pass in every request after authenticating? in the web application world cookies and sessions were used for this, that is the other glue that I'm missing, I will use the facebook user id to create and link my own users to that authentication successful attempt, but it should return 'something' that I will use for authentication for further requests, this something, this glue, is what that I'm missing. – Eduardo Naveda Oct 17 '14 at 12:42
  • those are the "access tokens" :) - but you don´t need to worry about them when using an sdk. just use the login code implemented in the sdks and they add the access token correctly for every api call. – andyrandy Oct 17 '14 at 12:48
  • isn't that against Facebook? I'm having a hard time putting the pieces together, I would like a generalized picture, imagine the following, now my provider based - authentication needs to go along with a traditional user-password authentication, I have two tables: user and identity, how would I go about making those "access tokens" viable for both my authentication methods? – Eduardo Naveda Oct 17 '14 at 12:52
  • i am not sure what you mean. what should be "against facebook"? if you want to use facebook login along with traditional login, it´s a bit more complicated - for facebook login you don´t have any password to store. you can store in your database how the user authorized - with facebook he does not have a password and you only need to store the id if you need to identify the user. and you can present some form after facebook login where the user has to enter additional data. you would just have to check if a returning user with facebook login already filled in the form. – andyrandy Oct 17 '14 at 12:58