Develop Reference

How do I ensure mobile apps doesn't steal user/password calling my REST API

We're developing a REST based API that developers would call from their mobile apps, e.g. google play apps.
How can we make sure that the app developer doesn't steal the users user/pass by storing them or sending them to "EvilServer".
If we do not trust the app developers, does a technical solution to this problem exist?
Could one solution be to have our own trusted authentication app on the native platform and let app developers use it to authenticate?

What I would recommend is to first remove the ability for a third-party application to log a user to your service using his credentials, so there is no reason for an app to ask for the user's credentials in the first place.
I would instead provide an OAuth authentication endpoint (take a look at the server-side flow) to third-party developers in order for them to use your authentication service to register and authenticate users in their app. This is interesting because users have to be redirected to your authentication endpoint when they log in, so there is no chance a third-party application can have access to their credentials at any point.
However, nothing prevents the developer of an evil app from creating a fake form requiring the user to provide sensitive informations in order to log them in, such as an email and a password.
In this case, you can do two things :
First, educate your users (e.g when they create their account) not to provide their credentials on any other website than yours. This is typically done by banks and insurance companies.
Implement Multi-Factor Authentication to add another layer of security to your authentication process. Most web companies such as Google or Twitter allow you to require that while providing your usual credentials when logging in, you are still required to validate the login process using an out-of-band medium. They typically achieve this by sending you a PIN code via SMS on your phone that you must input on a web page to finish the login process.
As such, if someone tries to log into one of your user's account, it will fail unless they have also access to the user phone.

OAuth attempts to solve this problem by sending the user off to a provider to authenticate before bringing them back to the original site or app. This is how the "Log in with Facebook" and "Log in with Twitter" systems work.
There's a handy diagram at http://www.quora.com/How-does-Login-with-Facebook-option-work-on-third-party-websites that shows how the requests are passed back and forth.

Android App: How authenticate via web-based login

I am writing an Android app that makes calls to a REST Api. The user must be logged in and in order to do so, he must authenticate on the server which in turn redirects to the Identity Provider of my university.
My idea was to let the user log in via the android in-app browser and then extract the session cookie (and csrf, if necessary) into the app's AbstractAccountAuthenticator once the user is logged in.
How can I do this? I would also be happy about some helpful links. And secondly, is my way really the way to go?

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.

Leverage Twitter / Facebook credentials by pulling information from other app

I'm being asked if it's possible to have the ability to leverage facebook and twitter credentials by pulling account information from apps that are already installed and authenticated.
This means: an app is running and the user is logged in through FB or TW. Then, it launches my app. Could get those credentials and keep the user logged in on my app too?
I think this could be not so good to do it, but they are asking to me for an answer.
I did research and didn't find anything related, so I am thinking that it's not possible.
Could anyone confirm this or tell me how it could be done?

No, you can't. Each application must be registered on the respective social network, to obtain a application key and application secret. You then have to request a authorisation token from the server of the social network. Since the token is based on the specific application key and secret, even if you would be able to leverage this authorisation token (say on a rooted device), it would be useless to you, because you´d also have to know the key and secret. Ands Facebook matches the app signature as a extra layer of security.
Plain and simple no :)

If you just want to share data to Twitter or Facebook from your app, you should do this by using a share Intent. This way you push the data to whatever app (FB or Twitter, or others like email and messaging) while the user picks which app they choose to publish this data on. See more info at the developer blog here: http://android-developers.blogspot.com/2012/02/share-with-intents.html
And tutorial here:
http://mobile.tutsplus.com/tutorials/android/android-sdk-implement-a-share-intent/
If you want to do specific things with the authenticated account, like retrieve the user's timeline or wall posts, I don't think you'd be able to borrow that authenticated token from another app. You will have to register your app with each social network, ask the user his/her credentials and obtain a token. Then you can grab data from these services.

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.