I have currently flag my Facebook app as Native or desktop app, with Is App Secret embedded in the client set to Yes.
I can retrieve a short lived access token just fine, but when I try to exchange it for a long lived one, I get the following error:
The request is invalid because the app is configured as a desktop app
My question is: is there a special flow to get a long lived token in this case or that's not possible by design?
My question is: is there a special flow to get a long lived token in this case or that's not possible by design?
There is no other flow.
The message implies this is by design. They probably don’t see any need for using extended tokens in desktop apps. “The user is sitting in front of the thing, so if the short-lived token has expired, they can just go through the login flow again to create a new one.”
Related
I am building an application that does not have a client interface.
At the setup step: The user logs into the server throught a browser once using oauth, and the server makes sure that the client is identified.
From this point on, no browsers are invlovled. It all happens in the background.
It then keeps acting on behalf of the user for as long as the user can be validated.
That means that once in a while, my server needs to call the oauth provider to validate the user still exists.
Until now, I have only used google oauth: Once in a while, I would call the refreshtoken api, and get a new token indefinitely from the server side. (you need to ask for "offline access" when you get the user token).
Now I would like to use facebook as well, but reading their APIs, I see no mention of a possibility for a server to refresh it's tokens:
https://developers.facebook.com/docs/facebook-login/access-tokens/refreshing/
It looks like it all has to be done from the client device.
As I have no client device, does this mean that I cannot write this sort of app with facebook?
I think your scenario can be covered through Facebook's mechanism. But you need to support a re-login if some error occur while using long lived access token. This can happen due to security measure taken by Facebook (ex:- data breach, cryptographic breach) or when user revoke tokens or change password or when tokens are not used for a longer time.
Steps to follow (According to their docs),
Obtain a User access token
These are short lived
Short-lived tokens usually have a lifetime of about an hour or two
Exchanging Short-Lived Tokens for Long-Lived Tokens
These have life span of around 60 days, even when they are not used.
long-lived token generally lasts about 60 days.
Basically, once you obtain a long lived token, you can use it from the server application. During this process, you required a client which used browser only to obtain short lived access token.
But as previously mentioned, these tokens can expire,
These tokens are refreshed once per day, when the person using your app makes a request to Facebook's servers. If no requests are made, the token will expire after about 60 days and the person will have to go through the login flow again to get a new token.
So you will require to obtain new ones by going through above two steps.
I would like to add a new option to my application that allows users to post images to their Facebook albums or on the wall. As of now, the most unclear point is how to organize authorizaton process in the DESKTOP application. Official documentation says that I can use short-lived or long-lived access tokens. There is no any issue with getting short-lived access tokens, but I want my application to ask a user for login/password rarely.
I see 2 possible options.
1) Use short-lived access tokens
When a previous token has expired, I need to ask Facebbok for a new one, but for that I need user's login/password.
Questions:
1.1) Is it a good idea to store and encrypt somewhere on disk user's login/password and to ask Facebook for a new short-lived access token using user's credentials in the background (i.e. user won't see login form - this is hidden) ?
1.2) Is it a good idea to store and encrypt short-lived access token on disk to reuse it if a user just restarted application and token is still valid?
2) Use long-lived access tokens
This would be ideal for me. Even if access token has expired after 60 days, my desktop app will ask for a new one.
Questions:
2.1) Is it possible to get long-lived access token by DESKTOP application directly from Facebook? Is it needed to implement additional Web service for getting such token (I know that just server (not client app) can add app secret to request for long-lived token)?
2.2) Even if I able to get long-lived token from the Facebook directly, is it a good idea to store and encrypt it somewhere on disk for further reusage? How apps usually story it?
I will appreciate any HELP!!!
I don't understand Facebook App Config Advance.
With Authentication part: there are option which user can choose: Web or Native/Desktop.
Facebook said that "Only select native/Destop if you have embeded your app secret in your client app."
Does it means when I set it as Native/Desktop App, I can't authorize with web sdk?
There is an API call to extend short lived token for a long lived one
https://graph.facebook.com/oauth/access_token?client_id=x&client_secret=x&grant_type=fb_exchange_token&fb_exchange_token=x
I think that option enables this call but am not quite sure about this.
Basically if you want to get long lived access token using only your desktop app (without implementing this call in server code) you should check this.
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.
While reading Facebook's post regarding offline_access permission removal, I was thoroughly confused by their reference to short-lived and long-lived access tokens.
This page mentioned
The duration for which a given access token is valid depends on how it
was generated
But I failed to find any further information.
Anyone has insights on how this determination process works in detail?
The access token your app gets for a Client-Side authentication is short lived (about 2 hours), but you can extend it and get a long lived token using the new endpoint with a valid access token.
In the Handling Invalid/Expired Access Tokens it says under Desktop Web and Mobile Web apps which implement authentication with the Javascript SDK:
Calling FB.getLoginStatus() or ensuring status: true is set when you
call FB.init() means that the next time a user lands on your
application and is signed into Facebook, the authResponse object you
are passed as a result of those calls will contain a fresh, valid
access token.
In this case, its simply the act of the user using your application
which implicitly generates a new access token.
If you use the Server-Side authentication flow then you will automatically get a long lived token (about 60 days) automatically.
When that expires you have to send the user to re-authenticate in the same flow (code exchanging).
You can of course use both methods and that way you can get a long lived token in the server and a short lived token in the client.