Develop Reference

Security in the android application

I recently developed an application which was the financial app and it had undergone security vulnerability testing.
One of the point identified in the testing was-
Account Takeover Through Insecure Direct Object Reference-
The comment provided was as below-
During security assessment, it is found that insecure authorization controls in the Android application allow an attacker to make requests on behalf of different users. It allows an attacker to take over any user's account.
The application completely lacks authorization controls which allow an attacker to make requests on behalf of any user.
The remedy provided was-
To prevent this, ensure user's access rights are restricted to the correct privilege level and not just by the pages available to the user in the interface of the application.
Does this mean a role-based system? My app does not need multiple user roles. There is the only single role "End User" who will be using the app.
Can someone provide insight?

You need to consider the following,
Use Authentication methods for the web APIs such as basic auth, OAuth 2.0, OAuth 1.0
Use session manager for the user, even if only one user.
Use Gradle to save the data such as URL, token, token secret etc.
Use minimal 3rd party libraries.
Use proguard
Hide all logs
Change Debug variable to Release variable before release or test.

Implement OAUTH session management with access token renewal.

Each system has at least two roles: admin (privileged user) and (unprivileged) user. However, in real systems there exist several roles like editor, Finance manager, HR manager, etc. So, you need to provide these users with different level of access to the resources.

Server-side user auth for paid android app

I am working on an Android app for daydream that is paid and has no login screen.
I want to emulate the user auth flow that I used when developing for Oculus outlined here in which you first make a local license check, then use the data returned and the userId to make a server-side check from my backend to Google Play's over http/REST.
I can't seem to find a way to get an Android App's userId (or token) in order to make this check without logins. The current path I am heading down is one in which uses the sorely outdated License Verification Library (for local checks) as outlined here and then uses the Google Play Developer API to preform a server check.
Is this the proper way to approach this, or is there a better/more modern way to do this? One that perhaps models after the Oculus flow more? Additionally, I want to limit the permissions I need to request the user for, since with Daydream VR, the user must remove the headset to accept permissions at the moment.
Thanks

Check the Using OAuth 2.0 for Web Server Applications as it's about handling OAuth on the server side. The flow you've shown is also a bit similar to the Web server applications diagram.

Least invasive way to uniquely identify Android user

How can you uniquely identify a user who has installed your app so that:
You will know it is them if they delete and reinstall your app;
You will know it is them if they install your app on a second device they intend to use simultaneously?
Just as an example, I see that the Netflix app will automatically link to your desktop account without any user interaction. I'm guessing that they use accountManager.getAccounts() or similar method, because they also require the GET_ACCOUNTS permission. But of course that permission is marked as Protection level: dangerous. Is there any technique to do this that is less invasive or potentially alarming?
The key to answering this is to be both simple (for the user) and minimally invasive. Android provides heaps of ways to identify users and many of those ways involve piercing a user's privacy, and if that is the only way, I will do what I do now (optional email registration). I just want a way for my app to know if a user already is registered in my system across installs without having to interview the user (username/password, email address, third-party OAuth, etc).
My main reasons are:
I don't want support requests from users who orphaned their content after a reinstall; and
I don't want to host lots of orphaned content.

Have a look at Firebase Authentication. It's quite seamless and does not require much effort to incorporate. Also it does not feel intrusive or cumbersome to the end user.
Here is a video tutorial by Google.
EDIT:
In case your users are sure to have a cellular device with a phone number, you can use AccountKit. It is also what they call OTA (One Time Authentication). AccountKit uses just the users phone number to verify and validate users.
EDIT:
Firebase Authentication now features 'Phone Verification' which is similar to AccountKit mentioned above. Both are good services. However, Firebase phone verification lets you make your own UI from scratch (which means a lot better control than AccountKit). Also, if you don't want to make your UI, you can always use FirebaseUI

i have implemented something that seems little similar to your thing by push notification , i can get error if user uninstalled my app(and from the registration id i get the user) , and if he re installed he obtain a new registration id , and try to get the user UUID for different devices

I think the simplest way would be using UUID and storing the hash on sharedPreferences. You should generate the UUID as earlier as possible in your app.
sharedPrefs = context.getSharedPreferences(APP_SHARED_PREFS,Activity.MODE_PRIVATE);
if (sharedPrefs.getString("YOUR-KEY-TO-THE-UUID") == null || "".equals(sharedPrefs.getString("YOUR-KEY-TO-THE-UUID"))){
prefsEditor = sharedPrefs.edit();
prefsEditor.putString("YOUR-KEY-TO-THE-UUID", UUID.randomUUID().toString());
prefsEditor.commit();
}

I think that the best way would be implementing login with Google or Facebook. This is quite seamless for users, safe enough (as Google and Facebook considered trusted), you do not need to implement your email registration and you will have identity across devices.

If your app is Android only and you'd like to provide identity without any account creation for the user, I believe using Google Account name/id is the best choice (Accessing Google Account Id /username via Android) since you have to use Google Account on Android phone (unless you root it, delete Google Play Services etc).
If you'd like to only address the first point of your question (identify after reinstall) there's a Device Id -Secure.getString(getContext().getContentResolver(), Secure.ANDROID_ID);
though it's not 100% reliable (f.e Factory Reset resets this value)

The standard for achieving this sort of functionality is through the use of JSON web tokens (JWT) in conjunction with standard restful api traffic.
Assuming your android application interacts with a RESTful api for all crudlike operations and business logic, then using a JWT as an authentication identifier to your api can work quite well. You can embed information in each JWT allowing you to identify whatever you like (the user id in the database, the device id of whereve the user logged in from, etc). A JWT is essentially a datastructure allowing you to store information to be used by the API.
Some basics for how this works:
Getting the JWT into the app: A user logs in to the application using their username/password. The
api then returns an encrypted JWT to be used by the client for all future requests. Don't try to do
the encryption yourself. Any language that can handle serving an api
will have libraries for this.
Using information in the JWT: The JWT is itself a datastructure. For example, it might look like this:
{
user_id: 1,
device_id: 44215,
device_os: android,
}
Your api will decrypt the JWT when it is supplied for
authentication via the request header, and then have that information available in the
context of the session.
If you provide the language used by your api then I might be able to recommend a library.
I will conclude by referring to the final requirement you submitted which states essentially that you do not want to have to interview the user across installs. If I understand your meaning, that you want a user to be able to simply install the application and begin using it without supplying authentication credentials, then there is no way to achieve that securely. You might be able to come up with a hackish way to get it to work, but it will be fundamentally insecure.

Authentication, android, private API, how to glue the parts together?

Let's say I have this application developed for Android which needs to use a Facebook (or Twitter or Google or all of them) based authentication so it can access this private API I've developed with nodejs' Express for example (could be any other platform too). I've read this answer here that gave me a hint on how to associate my authentication model with my user model (and another one here that made me realize those two parts are different), Facebook authenticates and I use some information they provide to create an "identity" for this user, but what exactly is this information that will create a link between the user and the identity? no abstract terms please, do I need to use and send either the access token or the Facebook user id? or would I just send the access token and let the server get the user id?
Regarding new requests after this user has been authenticated, I've read about API keys of some sort, which are basically some random strings that I should add to my identities (or users? this part confuses me) entities, and they should be securely stored in the mobile device as a mechanism to authenticate further requests, but how do I securely get this random string to the device in the first place? am I misunderstanding the way API keys work? are Facebook authentication and API keys mutually exclusive? if so, what would I use for further requests just using a provider for my authentication? it seems illogical to pass the access code in every request, even more so passing the user id.
The focus of this question is for me model a solid strategy for managing this authentication-user-identity behavior, would love any insights on how has this been done before since the material I've found in SO and the web has been very lacking, often referring just to server side implementations or just authentication answers, not addressing the issue of further requests.

The Facebook/User ID is there to identify the (returning) User. Keep in mind that you only get an "App Scoped ID", not the "real" ID - it will be unique in the App, but different in another one. See changelog: https://developers.facebook.com/docs/apps/changelog
Access Tokens are there to make calls to the Graph API. There are 3 different Tokens (App Token, User Token, Page Token), you can read more about them in those articles:
https://developers.facebook.com/docs/facebook-login/access-tokens/
http://www.devils-heaven.com/facebook-access-tokens/
You can store Access Tokens for later, but in most cases you don´t need to store them - only if you need to access the API while the User is not using your App.
In general, App Tokens can be used to request public stuff and to change App settings. User Tokens can be used to request (or post) User stuff and Page Tokens can be used to request insights of a Facebook Page and other things.
If you want to deal with Access Tokens on your own, make sure to activate appsecret_proof in the settings. I suggest reading this article about securing API calls: https://developers.facebook.com/docs/graph-api/securing-requests

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.