Best Practice to Verify Facebook/Twitter Connect. (Prevent reverse-engineering keys)

Question

I may be a bit paranoid with the whole process in general, but I want to do the right thing to make sure only legit users can create accounts for our service, and we DO NOT INCLUDE the api secret embedded in our binary which may be 'reverse-engineered'

We want to do one-tap'Sign In With Twitter", and "Sign in With Facebook", and we can use the respective SDK to get the authToken.

For example.:

With Twitter:

As mentioned here https://dev.twitter.com/twitter-kit/ios/twitter-login provides the following information from the SDK,

authTokenproperty
authTokenSecretproperty
userNameproperty
userIDproperty

But I will have to embed the keys in [[Twitter sharedInstance] startWithConsumerKey:@"your_key" consumerSecret:@"your_secret"];

We want to verify that this authToken is in fact legit, and our server needs to verify this information. What is the right way to architect this whole process?

With Facebook:

FBSession *session = [[FBSession alloc] initWithAppID:APP_ID permissions:permissions
 urlSchemeSuffix:nil tokenCacheStrategy:[[FBSessionTokenCachingStrategy alloc]
 initWithUserDefaultTokenInformationKeyName:@"TEST"]];`

If a hacker is able to reverse engineer this APP_ID, or Twitter Keys, how can we verify that this information on our servers to make sure this is infact the legitimate?

What is the best practice for it?

Answer 1

Let's turn this problem around for a minute. A malicious user has complete control of a copy of the client (as is always the case), what can they do with it?

The attacker can authenticate via your client using any account they control. They could then make Twitter/Facebook API calls using your credentials. Is this a problem? Since the attacker has credentials for these accounts this does not offer them any control they did not already have. They could use it to exhaust API rate limits and their activity might show as coming from your app but there's not much you can do to stop this while still allowing use of your app. Maybe it offers a reason to make your API credentials updatable but any updates will be sent to both benevolent and malicious users alike.

What other threats do you see? How are these permissions used and how could they be exploited?

Do you identify users using these accounts? Could an attacker in control of the client use this to generate new accounts with fake credentials or attempt to assume control of other user's accounts?

Are you storing or transmitting the resulting oauth session credentials? Could an attacker intercept them to gain control of other user accounts?

Answer 2

About keeping the consumer secret etc. safe, here is another SO question with a pretty good answer: How to keep the OAuth consumer secret safe, and how to react when it's compromised?

Answering the other question, verifying the user identity on your backend: What you should do is transfer the auth tokens needed to use the twitter or facebook API in behalf of that user to your backend (preferably of course in a safe manner via SSL etc.), and make a request like GET /v2.2/me (facebook graph api) from the backend. Now you can compare the data and know that the user really has provided a real facebook or twitter account to you.

Answer 3

Twitter/FB provides identification for a user, but not your app. You should have separate credentials for your client app (to tell your server side that this is a trusted app). In that case, your server side can trust communications from your app.