Develop Reference

Secure an API for mobile apps call

I've been doing a lot of search about secure my api for mobile apps for Android or IOS.
Almost all examples tell user provides an user id and password somehow in a exchange for a token.
But how to prevent someone else to consume my api without my consent?
Face the following scenario:
I expose an API,
I develop, then, an app for android to consume it,
I develop, then, an app for IOS to consume it.
Other developer performs a rev. engineer in my app, creates his own app and starts to consume it without authorization.
How to prevent that?

Short answer: you can't.
Little longer answer: If you know what you are doing you can always reverse engineer a given application and use its api. You can only make it more difficult and time consuming, using authentification via tokens and device ids or usernames is a good first step. Apart from that: why would you want to close your api to outsiders? If your server code is written well there is nothing to worry about.
You can maybe secure your API on a legal basis and sue developers who use it, but that is a completely different topic.
Some clarification regarding securing the API and securing content via the API. Assume you create a server where you can send user/password and receive a token if that combination was correct. For the account-page you send said token over and the server verifys that that token is valid and returns your account page. You secured the actual content of the API. That is obviously very possible and almost a must-have unless you have no user-specific data. But still everybody can send the exact same initial request from their custom app, sending a user/pass and again receive a token, etc. You cannot really prevent the request itself or even determine that it was not send by some service not authorized by you. You can send some hashes along the request to add some security by obfuscation, but since your app has to compute them, so can the reverse engineer.

Yes, login api are open but they return a token only on successful match in your database. You should focus more on security of your data than unknown hits at your api.
SignUp API can be used for creating a user, and login for returning token of that user. Only if malicious developer has credentials, then he can access tokens and auth APIs. There is also something about DDOS attacks so you can maybe write logic to temporarily block IPs where hits frequency is high.
You can also store device ID of signing user, which seems idle for your scenario. Entertain hits from that deviceID only. Similarly, user can add more devices with their credentials. I think even Google does that (generate alerts if user creds are signed in from new device and add the device to list if user confirms). Hope this helps.

Android App registration / Authorisation

I am quite new to android and recently started building an application which requires
Registration using a google id.
Continuous interaction with a back-end server.
For the registration , i was wondering if it is possible to have a python webapp on Google App Engine which has the OAUTH2 authentication .
This page if opened in a webview should return the token to GAE (please correct me if i am wrong here , because i am not sure the token won't just go directly to the app).
Then again on the backend i generate a token(newly generated) and update the user tables with this new token and pass this onwards to the application.
Every subsequent request made by the app will be referenced using this token.
Is this feasible or is there a better standard way to do it (i do not want to use the login info already stored in the phone) ?
Also , how can i get information from a google account(name,email) like Facebook has access to the graph is there a google counterpart ?

As far as I understand, you implement your Android app using WebView. This means that the app interacts with the server the same way as the built-in Android web-browser. As a result you don't need to add anything special to your Android app with regards to authentication.
Built-in Users service
In GAE, you get out-of-the-box support for three different types of authentication where all of them are designed in a way that your app doesn't store user credentials but rely on user authentication from identity providers:
Google Accounts (e.g. jonny#gmail.com)
Google Apps Domain (e.g. jonny#mydomain.com hosted in Google Apps)
or Federated Login (a.k.a. OpenID, e.g. Google, Yahoo!), which is going to be replaced by Login with oAuth2 (OpenID Connect)
All three types allow your app only access to very basic information of the user. Enough to match a returning user of your GAE app to their data, and an email address or unique ID, but that's it. For more, see below (oAuth2 consumer).
In appengine console, you can select your preferred authentication type in page Administration > Application Settings.
Whatever of these types you use, in your Python code you can use GAE's Users service which will deal with the authentication of your users. Basically, you just write something like:
from google.appengine.api import users
user = users.get_current_user()
if not user:
# The user is not signed in.
else:
print "Hello, %s!" % user.nickname()
On development server, you will be prompted with a dummy login page for requests where you require login or admin login. In live environment they will be replaced by GAE with real login page flow. There are also articles linked in the docs with HTML/JS examples if you want to show custom login pages to your users, for example User Experience summary for Federated Login
oAuth2 for authentication and authorization with Google
Regarding oAuth2, with the built-in authentication it is rather easy to integrate the builtin oAuth service, so your GAE app becomes a service provider, i.e. a user of your GAE app can share data with any 3rd party app or website through some simple API. You also can have your GAE app consume data that your users have stored somewhere else (e.g. Google) and they want to share with your GAE app (consumer). If you are especially interested into accessing user data in Google services, there is this good overview.
Custom user management
Finally, you could implement your own authentication mechanism, rather than relying (and depending) on GAE features. For example you can implement your custom user management based on webapp2. This means that you have control of the user-accounts and credentials, but aside of eventual security risks the disadvantage is that it can be really hard and tricky to integrate services and APIs like Google Cloud Endpoints.

Using Facebook scores API in an Android App?

I am integrating the scores API for facebook in an Android game. I had the exact same problem as this question: Facebook Graph API Explorer won't POST scores. The fix was to set my app as Web instead of Native/Desktop. Is it because scores API should not be used by native games? Is it somehwat dangerous to set up Web for a Native app?
Thanks

I have noticed this too, however I wondered if it is 'by design' as to use the Facebook Scores API you need access to the app access token (in order to do things like submit scores) however this isn't considered a safe thing to use from a native application. Here is a quote:
"App Access Tokens should only be used when the posting functions are originated directly from your servers in order to keep them private to the app. For example, you should not publish using an App Access Token from within a native mobile app. Doing that could allow the user to obtain the App Access Token, which could then allow them to take actions on behalf of your app. Instead, you should have your native mobile app queue actions up with your server and then have your server publish the stories to Facebook using the App Access Token."
Here is the website in question: http://developers.facebook.com/docs/opengraph/using-app-tokens/.
So, it sounds like the only way to really use the Scores API is to have the native application securely talk to a separate, secure, server (potentially on Heroku) then once that server has verified the passed data, it would then talk to Facebook and submit the score using the app access token (which it can safely use without the user getting hold of it).
On top of this, the Facebook Scores API only supports having one score per application (not per level, per mode, etc.) scores, so in order to have anything more advanced the extra server is required anyway, so a database can be stored that maps Facebook user IDs to the various scores one wishes to score.

Android APP that consumes a webservice how to authenticate users

I'm developing an android app that consumes a webservice that I will develop too (I'm thinking in using a RESTFul webservice)..
and I want to secure the connection between the app and the server but I need to authenticate users too..
My problem is in the last part, to secure the connection I think the best way to do it is to use SSL (https), am I wrong?
I don't know what's "the best way" to authenticate users, to make sure that a user cannot consume the webservice as another user..
I have some ideas, like using a authenticate(login,pass) method on the webservice that returns a token.. And for any operation that requires authentication the user would need to pass that token as a parameter.. The thing is, is this a good way to do this? whats the most common technique used to auth users in a situation like this?
If a token based auth is a good idea how should I generate the token?
Sorry for this long text..
Any help will be usefull
Thanks

Make sure you understand a trendy standard like OAuth before you go down that path. Most OAuth flows are centered around a user logging in to your server through a web browser. This can lead to pretty bad user experience for a mobile app. The standard does allow for alternatives. Here's a decent introduction.
You could also use an existing identity provider like Google, Facebook, Twitter, etc. instead of implementing your own authN/authZ. On Android, you can ask for a Google auth token using the AccountManager. This usually works because the user needs to be logged in to their Google account to access the Android Market. Anyway, this will prompt the user to grant authorization to your app. You could then use the Google auth token to login your user to your service with your own token. The login would essentially be your server verifying the Google token is valid (by contacting Google's servers) and then issuing its own token to be used for calls to your web services. If you don't like Google, you could use the Facebook SDK, etc.
As for what to use for tokens... The OAuth spec has stuff on that as well. You could do something as simple as a random string or something as complex as encrypted SAML assertions.

You should implement a token based OAuth, which will require the users to log in once, and then permanently have access.
You can use Google App Engine which already provides user authentication services for you (your Android users most likely already have google accounts) But this is only one of many options.
You can also look into Amazon's Identity Access Management (IAM) which will allow you to manage the users who have access to your web service, and authorize them accordingly.
I think the best way to do it is to use SSL (https), am I wrong?
This only prevents certain types of malicious use, but not everything. There is still nothing to prevent people from accessing your database on the phone, and retrieving credentials that way.

Effective OAuth for Google APIs from Android phone

I am trying to get Authorization for Google Buzz,Contacts from an Android application.
The flow is similar to this.
The user chooses if he wants to use Buzz.
Using OAuth/Client Auth, we need to get a one-time authorization code.
This code would be used by a web service to periodically read Buzz feeds.
Now, the problem is how do I obtain the authorization code (Not temporary token) from the Android App and send it to the webservice.
I could use the normal OAuth2.0 and use my webservice as the redirect URL to obtain the code. But in that case how can I let the webservice know that the code pertains to which user?
Can I pass extra information with the OAuth dance?

I strongly recommend using OAuth 2. The flow is much better for the end user and it's a lot easier to implement something like this. Additionally, it uses bearer tokens, which means that you can maintain your refresh token server side where it's actually secure and only ship access tokens to the Android when they're needed.
The downside of this approach is that effectively every time your app loads it needs to phone home to get the latest access token. But once it has that access token, it can make whatever API calls it needs to, directly to the Buzz and Contacts APIs.
However, to do this, you don't pass extra information with the OAuth dance. Instead, your Android app needs to have already securely identified which user is signed in with your app, and then make sure the server only ever sends back access tokens associated with the authenticated user. If it doesn't have an up-to-date access token for that user, it would need to make a request out to Google's authorization server to get the latest access token, and then pass it up to the client. So there's certainly a strong potential for some latency there, because that generally needs to be a synchronous call, but that's usually a small price to pay for the advantages OAuth 2 gives you over OAuth 1.