Assuming it is possible to transfer the Facebook API access token from some web app to my mobile app (via physical storage or network), will my mobile app be able to use that token as a regularly acquired token (as if the mobile app itself requested the token from Facebook)?
Is this procedure allowed in the Facebook API's terms of service?
Will the mobile app be able to cache that transferred token and use it as its own?
Basically, what I want is for the user to do Facebook Login and authenticate on one machine, and use the acquired token on a different one (e.g mobile app).
Is there a better way of doing this?
You can set your mobile app to go through facebook's oauth steps onload and if the user has already authenticated the app, he will get logged in right away, since you'll get an access token at this point of time, save that in the mobile app.
Automatic login triggers are now being used on both stackoverflow and quora. (if you sign up here through facebook, when you visit the site, you'll get signed in again - same for quora).
Also, access tokens grant access to a particular 'facebook app'. If your mobile app uses the same app id, then you can certainly reuse the same access token on the mobile device.
yep, we can reuse it. I got an access token from mobile app then it's applicable on web browser.
Related
Following up on the design outlined in Design for Facebook authentication in an iOS app that also accesses a secured web service, and specifically the concern listed in https://stackoverflow.com/a/12912616/5154090: what would be the mitigation?
Specifically, I have a web server that exposes a REST API which is consumed by a mobile app. I'd like users to authenticate to the server (via the app) using Facebook.
Now, an apparently common flow is for the app to redirect the user to Facebook, where they will login with their credentials. The app will then get a token which it will send to the server, and the server will validate the token using the graph API.
But how can the server make sure that the token really came from the app? Specifically, what's to prevent a malicious app vendor from re-using my app ID? After all, the app ID is hardcoded into the app and can therefore be extracted and used by a malicious app. If users log into that malicious app with Facebook, then the malicious vendor can get tokens with my app ID and can impersonate users of my service.
How can one protect against this?
To summarize for anyone else who happens to contemplate this - there is indeed no way to prevent the client ID from being spoofed. This is one reason that developers are discouraged from using the OAuth implicit flow in native apps as pointed out by Andre D in https://stackoverflow.com/a/17439317/5154090:
the use of the Implicit Flow with native apps is NOT
RECOMMENDED.
(see https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-09#section-8.5).
In practice, if anyone mounts this attack, then the user will download App A (a malicious app) and will then be asked to authorize App B to make actions on their behalf. As far as I can tell, this is generally the only indication that an attack is taking place.
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.
My question is related to, but not exactly, this question.
I am currently working on a business directory Web site (similar to Yelp), in which businesses have their own pages. Let's call this app DIRECTORY_APP.
Businesses might want to have their latest Facebook status update shown on their pages hosted on our directory. Let's pretend we have a business named BIZ_1. The assumption is that those pages are public pages.
Apparently the Facebook Graph API can be used for this purpose. So I can send a request to Facebook to retrieve the latest status updates for BIZ_1:
https://graph.facebook.com/BIZ_1_PROFILE_ID/posts?
access_token=DIRECTORY_APP_ACCESS_TOKEN
&callback=callbackName
However, if I use this from the client side, our Web site's access token will be exposed to the public, so this is not a reasonable solution.
Now in the aforementioned question, Anatoly mentions that we can retrieve the access token by sending this request first:
https://graph.facebook.com/oauth/access_token?
client_id=YOUR_APP_ID&client_secret=YOUR_APP_SECRET
&grant_type=client_credentials
However if someone inspects the Network log, this will also expose our Web site's access token (is this correct or is this a different type of access token?). This solution also exposes our web site's app secret (is this safe?).
So to summarize, what's a safe way in which I can retrieve the latest status update of a Web page from client-side without asking the browsing user to first log in to Facebook?
I can retrieve the latest status update of a Web page from client-side without asking the browsing user to first log in to Facebook
You cant do that without login.
And I guess access token is not exposed.
Maybe the smart trick here is to use a social plugin. The Like Box will do what you want, without any issues. But, it's not greatly customizable. Even so, it's possible to get it looking nice on a page!
It also skips any login issues you mentioned.
I found the answer after some Googling. In short, the answer is no.
And here's an excerpt from Facebook:
Security Best Practices
App Secret and App Access Token
The App Secret is used in some of the Login flows to generate access tokens and the Secret itself is intended to secure usage of your App to only those that are trusted. The secret can be used to easily create an App Access Token which can make API requests on behalf of any user of the app, which makes it extremely important that an App Secret is not compromised.
Therefore the App Secret or an App Access token should never be included in any code that could be accessed by anyone other than a developer of the app. This applies to all methods of code that are not secured like client-side code (such as HTML or Javascript) or native apps (such as iOS, Android or Windows desktop apps) that could be decompiled.
We recommend that App Access Tokens should only be used directly from your app's servers in order to provide the best security. For native apps, we suggest that the app communicates with your own server and the server then makes the API requests to Facebook using the App Access Token. For this reason, if your 'App Type' under Advanced Settings in the App Dashboard is set to Native/Desktop we assume that your native app contains the App Secret or an App Access Token in the binary, and we do not allow calls signed with an App Access Token to proceed. The API will behave as though no access token was provided.
If your App Secret is compromised, you should reset it immediately in the Basic Settings of your App Dashboard.
I was wondering if user access tokens that are recieved through one platform can be used to access and make facebook calls through another.
For example:
I have a mobile app and a web server that work together. A user signs in through facebook on the mobile app(through single-sign-on). The user then uses the mobile app in a way that an internal service requires that an external service call to facebook is necessary. The internal services relays this to the web server, and the web server makes the actual call to facebook.
Work flow:
User signs into mobile app
mobile app sends user access token + service call needed to web server
Web server makes external call to facebook and returns information to mobile app.
So in short, the mobile app is not making the facebook calls, but the web server is.
My question is that if I authenticate a user through the mobile app, can I pass(and store) the users access token and use that to make calls to facebook through the web server?
The answer is yes.
I've done this successfully with mobile SDKs (Android & iOS) using the Facebook authentication to obtain an access token, then passing this access token to a PHP web application which successfully uses it with the PHP SDK client library.
The access token is also the only piece of information that needs to be transmitted.
As long as the application key and secret are the same on both clients, an access token should be valid on either.
I would like to implement an iOS app with Facebook login. I would like the users of my app to be able to interact with their social graph (i.e. post to their stream). For that purpose I would use the Facebook iOS SDK.
When the users are already authenticated with Facebook, they also should be able to use some services on the server side of my application. How can I verify a user against the services on my server?
In my iOS app I can query the access token (for my Facebook application) using the iOS Facebook SDK. Should I send that access token together with the facebook user ID to my server? Can the server verify whether the access token is valid? Or should only my iOS App communicate with the Facebook API? Can the server post to my Facebook wall, or should this be done exclusively throught the iOS app?
UPDATE:
Facebook now provides a security documentation / checklist:
https://developers.facebook.com/docs/facebook-login/security/
You have at least two options:
Send the access token to your Server and handle all requests to Facebook
using that token (if the token is invalid you get an error and just
pass it on to the client). => Safe but (a little) complicated.
Separate the communication between
your client (iOS App) and the Facebook API and
your Client and your Server.
Your app would handle all requests to the Facebook API through the Facebook iOS SDK and then communicate the resulting data, like all kind of Facebook ids, to your Server. This approach is totally insecure without some sort of encryption; you could send some cryptographic hash function to your server and validate it with a key stored on your server and the iOS App. => This method is (a little) easier to implement however less secure since the key can be stolen through reverse engineering. Moreover you would have to check the "I'm using encryption" check mark when submitting your app to the app store.
It actually depends on how much risk you are willing to take, what kind of requests you make, what kind of services you have and so on.
Can the server verify whether the access token is valid?
Yes, look here: Facebook access token server-side validation for iPhone app