I'm trying to create a server side access to a user's Facebook resources (photos/albums/etc).
I want that the user will authenticate once using its native mobile application, and that the server will be able to access user's data without the user interaction.
I'm trying to understand the steps I need to take in order to make it work.
I've read Facebook's: Login for Server-side Apps but I can't understand how to use the scenario proposed in there - because my server has nothing to do with user interaction (I cannot redirect the user to some login dialog) - the server is performing its own operation in the background whether the user is using its mobile application or not. What should I do upon token expiration for example?
More then that, I want that the user will be able to perform direct Facebook operation on the mobile itself, without the server intervention.
As I see it, this is the flow I would expect:
User's launches a native mobile application.
The user authenticates using Facebook's SDK on the native mobile app.
The user received a special token, that can be converted at server side to an access-token.
The token will be sent to the server and stored there.
If the server needs to access user's Facebook data, it uses this special token and converts it to an access token.
When the token expires - the server can extend it, using the special token, without any user interaction.
What data should be sent to the server from the mobile application after authentication. And how should the server use this data to access user's Facebook resources anytime?
I'm using the C# Facebook SDK for the server. But I think it is not that important, I need to understand the mechanics.
Tokens expire if the user does not continue to use the application. This is by design--an application should not continue to access the user's account if the user stops using the application.
When a user logs into your application, a token is given to your application, along with an expiration date for that token. You can use that token from your client or your server until it expires. However, there is nothing your server can do to extend the token if the user does not continue to use your application.
If the user continues to use your application, you will have an opportunity to update your server token. For example, in the Android and iOS SDKs, tokens are automatically refreshed if the user uses your application to make a facebook request. At that time, you can transmit the refreshed token to your server.
Related
I need to setup communication between my iOS/Android app and my PHP backend. I want to use facebook account only for logging in, there is no further communication with facebook. I have User accounts in my system and facebook_id is only a parameter to identify user.
Is it ok to verify the user by checking the token on the graph api from my backend just at the beginning and then only use my own tokens for communication or do I need to recheck if the user is still logged in on facebook from time to time (which is actually irrelewant for me as there are no fb interactions).
What else is there to consider?
Do I need a separate token for my server? Or do I use my App Secret
You should be able to use your application token.
The only scenario it might not work in is if the user deletes your app and decides to login again. From what I've read the app scoped IDs may change in this scenario.
I'm trying to build a Facebook-authenticated native mobile app (Windows Phone) that connects to a web service I am creating in Node.
I'd like for a user to:
Log in to Facebook on the mobile app via a native UI or web window
If logged in successfully, create or access server-side user account data tied to that identity
Use the authenticated session to make subsequent authenticated requestsvto that user's data via the native mobile app
My question is: What's the best approach here?
Should I...
Log in the client to facebook locally in the mobile app and pass the Access Token to the node service, and then somehow map the user to my service data based on their facebook account id? That seems grossly insecure if I just pass that token in the URL.
Log the user in via a mobile browser window inside my app, and then redirect back to my Node service in the same window? How do I then make subsequent authenticated requests natively in my app?
Do something else entirely?
Sorry this is so open ended but this is the first time I have tied these things together and although there's a lot of info on each part I've yet to find something that describes the overall pattern / best practice for this design.
Your question is quite opinion based...but still I will try to help.
First of all, you can pass access token in url, its not insecure if you use https. Even if logged into facebook from your mobile app, than also its going to pass a access token in url only. If you mean having the token in http://something.com/access_token, than its not how its should be done.
If you look into the Oauth 2.0 draft you will understand that its done through setting a header Authorization with the value being the token and token_type. Take a good look at the draft.
As your solution I think its fine if you just use the first method mentioned in the question by sending the access token in header as I mentioned in your app and in turn authenticating that token from facebook on each request.
If you think this is just too long a flow for authenticating every request from facebook, than you can get access token by sending request from your mobile app to server and let the server handle the access token and store it in database which you can authenticate each request.
In any case take a look at Passport module, it has facebook and other auth built-in and should be sufficient for your needs.
A lot of apps keep user logged in until user manually logs out like facebook, dropbox, etc.
I am wondering how they achieve it? There might be several approaches:
1)Do they store the username and password in a local storage, and automatically log the user in when they open the app again after a long time?
2)Or do they get a long-lived token from the server, and once the user login at very first time, the app gets a token from the server, later on they just use the token? The token will be valid until user manually logout from the app.
For #1, it will only work for native login, if an app supports "log in with facebook or twitter" it won't work.
So I just want to get an idea about how people achieve this feature? Is there any articles talk about it?
Most services like Facebook and Twitter use OAuth to manage the user session.
I use this external framework... https://github.com/nxtbgthng/OAuth2Client
It took me a while of reading and setting up to get right but it works now.
When the user logs in they get an auth token that contains an expiry date. When the expiry date comes the system automatically refreshes the token.
When I send a request to the server I send it via the OAuth framework and it adds the authorisation automatically.
I am working on a product which has both a desktop web site and a native iOS application. We are providing Facebook connect as a login option for our users in both contexts.
My intention was to share the same Facebook tokens via a secure JSON API for use in both contexts: when a user signs in on the web, the token is stored to our backend so that when the mobile client next runs, it can download the token and use it as well, and vice-versa. (* The detailed reasoning for this approach I explain at the end of the question, and is not essential to the question.)
The problem: when the iOS client uses a token to preset a feed dialog, if that token is generated by the web using the server-side flow, the dialog webview renders an error:
"An error occured with {my app name}. Please try again later."
This is reliably reproducible:
Generate a new access token using the server-side flow. Make sure you request publish_actions permission since you'll be using the feed dialog.
Using an incognito browser window (to get an empty cookie jar), view the m.facebook.com page that the iOS feed dialog would render in its webview: https://m.facebook.com/dialog/feed?access_token=SERVER_SIDE_FLOW_ACCESS_TOKEN&app_id=YOUR_APP_ID&redirect_uri=fbconnect%3A%2F%2Fsuccess&sdk=2&display=touch
Alternatively to #2 you could do all the work (which I have done already) of creating a dummy iOS app with the Facebook SDK, instantiating it correctly and presenting the dialog. It's just easier to go straight to the m.facebook.com feed URL for the purposes of reproducing the error.
If the token was generated by the auth flow initiated by the native Facebook iOS SDK instead of the server-side auth flow, the above feed url works perfectly fine, as expected.
Additionally, either token (mobile or server generated) works perfectly fine for posting feed items directly via the graph api. The problem is really just with the mobile feed dialog.
Is Facebook intentionally disallowing server-side generated tokens from operating in mobile feed dialog contexts?
Is this a bug with the feed dialog endpoint on m.facebook.com?
Or, hopefully, am I doing something wrong?
Why do I want to share tokens?
Since the offline_access permission is being removed, each client (web vs mobile) can benefit from having the other client refresh the same token when the user is active. This will lead to fewer instances of token expiry, and therefore fewer cases in which users must re-authenticate from scratch.
Likewise, users are not asked so frequently to approve additional permissions, since each client can benefit from the other's permission augmentations.
The tokens you get from the server side auth are different from the ones on the client side (I look at iOS/Android as client).
The server tokens are long lived one (60 days) while the client ones are short lived (a few hours).
The server side flow adds another layer of security where your servers authenticate against the facebook servers, which is probably why you get a long lived token automatically when using this flow.
If you try the debugger with an access token you will receive information about the token, such as the "origin" of the token.
For example a token generated from a client side auth (using js) has "Origin: Web".
That means that facebook indeed differentiate between tokens.
I'm not 100% sure about this, but from what you're saying it does sound like facebook is limiting the UI to the usage of client tokens and not server side ones, probably because the dialogs let the user do things without the need of the app to get permissions, and so if you have a 60 days token your app can then use it instead of the user and do things on his behalf with out having his permission.
I'm just guessing here.
What I would recommend you is to use the server token only on the server side, and let the iOS client handle his own token.
According to the Handling Invalid and Expired Access Tokens guide, it states:
iOS native applications
API errors are handled by the FBRequestDelegate interface. When you
detect an access token is invalid or has expired, your application
will need to multi-task over to the Facebook iOS app. Assuming the
user has not deauthorized your app, they will be immediately
multi-tasked back to your iOS application with a fresh, valid access
token.
Which means that you don't have to worry about the token getting expired on the client side.
If an mobile user have authorized the app for facebook via Single Sign On, is there a way the permissions can be used on the server side for offline access?
Scenario:
user uses the mobile app
user authenticates via SSO
app needs to use the user's permission on the server to check for certain updates
app pings the user via notifications if updates received
Can this be done?
You need to authorize at the app and obtain the Facebook token. Then you can send this token to your server and use it there without problems. You should ask for the offline_access permission if you want this token not to expire in a few hours.