Secure communication between iOS client, Facebook API and server - iphone

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

Related

Spoofing facebook app ID

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.

OAuth strategies for Facebook/Google services in mobile app with Rails background

I'm developing some iOS app with Rails background. I want to allow users authorizing through Facebook or Google. User mush be authorized before he will be able to make comments and estimate posts. It's my first experience of working with OAuth, then, please, check my steps for client-server architecture:
The App gets token/user_id from FB or Google
With every request (which requires authorization) to the server the
app must send user_id and token
The server checks if the token is valid
If all is good the server responds some data; if token is not valid
the server returns an exception code.
Please, tell me any advice you think is good. Thanks in advance.

Confused about an existing website with OAuth but now we add an API to the site

I'm writing an API for our product and I'm trying to understand how some basic OAuth works with regards to mobile apps that might leverage our (to be created) api.
Lets imagine that our website currently allows a person to LogIn to our site via Twitter OAuth.
On the callback from Twitter, our server retrieves the twitter OAuth result and if all good, then checks to see
if this user already exists in our DB (eg. lets assume the Email is the unique key). If they don't exist, we
create a new user.
Of course, we then log the user 'in', which means we create a cookie for them, for their browser.
So far - nothing new here. All normal stuff.
Now .. if we want to do this via an iPhone or Windows phone using their native language and the app's use our API, i'm not sure of the point where OAuth ends and our API takes over?
For example, lets pretend it's an iPhone app that takes advantage of our API.
The iPhone app will try to authenticate the user against their Twitter cred's. Ok, fine. But when it callsback, it's back in the phone, right? Not our servers. So then the app needs to try and create a new user? So then the iPhone might try and call /api/CreateAccount. But this means -anyone- can call this api? And how does the website really know they have authenticated? Only because the app says so? What's to stop the person from creating a malicious app and calling our API by flooding it with new account creations? And what about authentication to api resources? Forms Authentication isn't available here. So do people use querystring authentication over SSL for api calls? How does the iphone authenticate with -our- server?
I'm so confused.
Can anyone please explain the differences and common practices people are doing these days when they have a website and an api .. and use OAuth as the authentication mechanism, please?
The naive app would call not CreateAccount, but VerifyAccount with twitter's oauth set of data so you site and API could verify it. The site would respond with a unique userID and your iOS app would use that as it's internal user id. More info.

facebook user access token across different platforms

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.

linkedin connectivity from my native iphone application

hello everyone i am new bie in iphone development i want to connect to linkedin from my native iphone application i am currently having no idea how to connect to it please guide me how could i do that
From http://www.zhangkf.com/2010/06/linkedin-developer-network-oauth-authentication/:
Yes you can get connected with Linedin withyour Native Application by
following simple steps:
You get an API key from LinkedIn. This is also called a Consumer Key in OAuth terminology.
You build a feature into your site that leverages the user's LinkedIn network.
Your user clicks on your UI to request to use that feature.
You make a call to LinkedIn to ask to use our authentication. This is called getting a Request Token.
LinkedIn replies with an OAuth Token indicating that you can use the authentication system.
You send your user to a LinkedIn URL. That URL includes the OAuth Token you got and a few other parameters such as a URL for LinkedIn to
return the user to after granting access.
The user grants access to your application by signing into that page.
Upon successful signon, LinkedIn will return the user to your site.
You will then make a call to LinkedIn to get an Access Token.
LinkedIn replies with an Access Token for the user. You use that Access Token for any API calls to LinkedIn to identify the user on
whose behalf you are making the call.
Or
Download the Code from here,you could get it.Just Provide your API Key and Secrete Key
http://github.com/ResultsDirect/LinkedIn-iPhone
Or see this for details:
http://developer.linkedin.com/docs/DOC-1008
This sample is 100% complete and working, just add your app key.
Built with the latest XCode 4.01.
Uses a UIWebView so you have the option of customizing the browser UI.
Uses JSON instead of XML, which is the preferred best practice for most cases
OAuth is heavily documented so you know what's happening
Tested with iPhone 4, iPad 1, and the simulator on iOS 4.x.
http://lee.hdgreetings.com/2011/03/iphone-oauth.html