Develop Reference

Is it possible to know if firebase auth is from android app or iphone app or web app?

I wanted to know if when there's an firebase authentification, it's possible to get the source of this authentification?
To know if it's from my iphone app, android app or web app.
Why :
My web app isn't on the web, but on local server. I want to distribute this web app with server (It's for a personnal project but it could have 10 prototypes). So everybody can get my firebase config. And I don't want that someone can create account from the web firebase api because I accept google/apple and email/password auth. I can't disable email/password for my project purpose.
I hope this is clear.
To be more clear, if the email/password auth is created, is it possible to know if it's from android app or iphone app or webapp?
Thanks

The provided APIs for Firebase Auth don't give any indication which platform was used to create the account. Firebase intends for all accounts to work across all platforms using the provided SDKs and APIs accessible for each platform.
If you want to record your own per-user data in a database, you're free to do that. Note that this is not really "secure" in that each user could effectively manipulate your database or APIs to indicate whatever they want about their platform. If you do not have this sort of security in mind, then you can simply trust your own code to write, and late read, the user's platform in a database after they sign up.

To be more clear if the email/password auth is created, is it possible to know if it's from the Android app or iPhone app, or web app?
Yes, it's possible. Let's say we want to know if a user has signed in from Android. When the user creates an account from an Android device, most likely you are storing user data as objects in the database. The simplest solution I can think of is to add another property in your User class, called "platform" and set it to "Android". If the user signs up with an iPhone, then set the property to "iOS". Same thing for the web. Knowing that the user might change the device, every time the user opens the app check that value against the OS the user is using. If the OS is changed, also change the value accordingly. This way you'll always know the OS the user is using. If you allow the users to use multiple platforms, for Android, there is a function called getProviderData():
Returns a List of UserInfo objects that represents the linked identities of the user using different authentication providers that may be linked to their account.
Similar functions can be found for the other platforms as well.

Is there any possibility to change programatically Square keys using Reader SDK?

We are using Reader SDK for payment processing in Square. In that keys assigned in gradle.properties file.
We have an android ordering application where multiple merchants access our application. We want to send payments to those merchants only.
We will ask Application Id and Password from merchant in our website and store details in our DB. Whenever merchant uses app we will get keys from service and need to assign
SQUARE_READER_SDK_APPLICATION_ID
and
SQUARE_READER_SDK_REPOSITORY_PASSWORD
Is there any possibility to change properties keys(SQUARE_READER_SDK_APPLICATION_ID , SQUARE_READER_SDK_REPOSITORY_PASSWORD) programatically with/without using “gradle.properties” file?
How can we update those keys programatically? Or any other possibility for this use case?

There's no need to ask for credentials from merchants (in fact, you shouldn't). What you would want to do is use Square's OAuth API. This flow would enable you to provide a link to merchants with whatever permissions you desire. If the merchant chooses to give your application permission, you would receive a code, which you can exchange for an OAuth access token. You would use said access token to generate a Mobile Authorization code, which is required to use ReaderSDK on each individual device. The gradle.properties then can keep using your (the developer's) application id and repository password without ever needing to change it.
The Mobile Authorization link I provided actually goes through the work flow of using an OAuth (instead of personal) access token.
Edit: I did notice you mentioned ordering app. Note that ReaderSDK is meant for in-person payments, not online payments. If you're wanting to take online payments with your Android application without using Square hardware, take a look at our In-App Payments SDK.

Need clarification on the proper way to Authenticate (Android app)

We have implemented a Backend Server and a DataBase, with RESTFUL API. We have an Android App that can ask the server to send certain data back.
We want to implement an authentication system on the Android App.
The team suggests that I use Spring and OAuth, but I personally have no experience with those, and am not exactly convinced about the necessity of this approach.
Other friends suggest using FireBase to authenticate the users.
Could I avoid using OAuth/FireBase and simply store in the Server's Database the user's account name and its corresponding hash-salted password, along with the salt? Every request sent from the client would contain the account's name (which could probably be a unique ID generated by the server on the very first request, and saved as a SharedPreference in the phone) and the password in clear. The transmission of the request being done via HTTPS protocol (thus using TLS/SSL), the password in clear would not be revealed.
What are the possible flaws to the suggested approach in the last paragraph? And if it is a flawed approach, considering we already are using Spring for the Server (Backend), should I go for FireBase or OAuth ?
Additional context:
Bare in mind that this is the very first largish-scale project that I have been working on (it counts as a 3-credits University course). We are 3 on the project. I'm studying Computer Science but I do not necessarily have a great grasp on all the systems we are using or plan on using.
We are creating an app which allows users to view on a map alerts published by certain databases (we are currently focusing on meteorological alerts) in real-time. We want to be able to implement a login system so that people can receive notifications despite the application being closed (we are allowing users to "subscribe" to areas on the map, to specify the regions they want to receive notifications for).

OAuth, or better OpenId Connect, is a protocol, while FireBase is just one of its' commerce implementations. It's always better to follow a standard where possible than to implement your own. To see the full list of the certified OIdcC implementations look at the OIdC site, and I see at least MITREid Connect project related to Spring. I think your custom solution will work for your custom case, but only until you think about any extensibility such as Google auth or accessing some 3-rd party API.

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.

How can I prevent other iOS/Android apps from using my RESTful API?

I have a pre-existing iOS & Android app, that I'm making an update for that includes a RESTful services API and Facebook login for user authentication. The general flow of the app is:
Users "logs in" to my app, via Facebook's SDKs, which return an access token to my app.
App calls a RESTful service, including the Facebook access token as a parameter (using HTTPS and SSL)
Service that is called, sends the received access token (and app secret stored only on my servers) to Facebook to verify who the user is, and performs actions based on that. Facebook is set to require app secret from server-side calls.
My app has gained popularity and has several clones already, and I want to prevent these clones from being able to use my RESTful API (as I am sure that they will try to do when I release the update). Let's assume that the clones are smart, are using the same Facebook access tokens that my app does (if this is possible), and are following a similar pattern & frequency of calling the API that my app does.
Is there anyway to ensure, or nearly ensure, that calls to my services are coming only from my app, and not the clones?
Thanks in advance!

You can do this by including a signature in the request, and verifying it.
App Side:
do something like: signature = md5( md5(url + data) + MY_RANDOM_KEY)
append signature to the data, or url, etc.
send call to REST api (as usual)
Server Side:
extract the signature from the body/url (and remove it from there).
calculate what you think it should be: signature_should_be = md5( md5(url + data) + MY_RANDOM_KEY) [keep in mind you've removed signature from url/data so that you get url/data in its original pre-hash state]
verify that signature and signature_should_be are equal
Doing this, along with SSL, should make your API secure enough.

You could do as Tommy Crush suggests and add a secret inside you application. But if you are up against clever opponents, this probably won't help. The attackers can either decompile your application or try to simply reverse engineer your signature algorithm.
It is important to remember that anything stored within your application should be thought of as already compromised, as an attacker can decompile your app and scour through your code as much as he/she pleases and extract anything he/she wants from it. You cannot rely on anything in your application to be safe inside your app, since an attacker can extract it from your app into their app.
It is important to note that you are using trying to use OAuth for authentication, which is not intended for. It is simply meant for authorization, which is not the same as authentication. Authorization simply gives you access to a resource, but does not tell you who accessed it, which is the problem you are facing. To authenticate your users as your real users (or as close as you can get), you would need to add a login service for your service - something like rolling your own OAuth-server, or similar. Then you can decide who can access the resource, which in this case is your RESTful API :)
If this is more work than it is worth, then Tommy's scheme is a good alternative :)

The de facto solution for authentication on restful APIs like Twitter and Facebook use is the OAuth mechanism.
You can find more details here: http://en.wikipedia.org/wiki/OAuth.
OAuth is supported from the majority of the languages with external libraries.
On Android for example there is the https://github.com/wuman/android-oauth-client library.