It's just a simple question.
I just tried to install my app which does Firebase Authenticate anonymously to
my android device.
I just found that Firebase Authentication makes new user every time I remove the app from my device and reinstall the app.
However, I want one device to have just one authentication id and not to make Firebase Authentication make duplicate users.
How can I do this? I thought I could do this by using Firebase Cloud Functions
and making it delete every users that didn't log in for a long time.
But, I'm wondering if there is any simpler solution for this.
Firebase Anonymous Authentication accounts does not persist across application uninstalls. If you uninstall the app, everything that was saved locally on user devices will be deleted, including the anonymous authentication token that identifies their accounts. There is no way to reclaim a token for a particular user and use it in the future again. You can use Firebase Anonymous Authentication to create and use temporary accounts to authenticate users in your application.
If you want to have the same token each time, you need to implement the fully log in with a supported account provider so that they can log in from all their devices without worry of losing their data or having duplicate accounts.
My company that I'm interning at is currently using Firebase push notification tokens for authentication from the mobile app to the backend and I am not sure if this is a good practice. The way it works is as follows:
FirebaseInstanceID service issues a unique token for every device as
soon as device starts
Mobile user sends login info to server; if server authenticates, the
mobile app then uploads the Firebase token to the database and it is
stored with the user such that the token matches with the user
On any subsequent logins, user sends the Firebase token retrieved from FirebaseInstanceID service to the server; the server attempts to match the token with a user
On clicking logout, mobile phone sends an empty token (i.e. empty string) to the server with their associated username
I have a feeling this is a very bad way to do authentication but I don't quite know why. According to my research the conventional way to do is that the server sends a temporary session ID to client, client stores it securely, and sends it to server for any subsequent requests. Can somebody explain what's going on with this Firebase business and why its good or bad?
The problematic your company is facing, from what i understand, it to authenticate devices with a back-end API.
Actually when it comes to mobile applications, it is a tricky question. If users do not have to authenticate personnally, you still don't want to open your services to anyone. So you want to have an automated authentication system that runs in the background of your mobile app and that identifies devices or app instances.
To do that you need two things : 1 - identify a device (or an app instance) in a unique manner. 2 - make sure that the used string to identify the device/app instance comes from a real device/app instance.
Firebase instance ID is maybe right now the best free way to do that. The mobile app asks for google services to generate the unique token. The mobile app then sends the token to your back-end API for authentication.
And then the back-end API makes sure, during authentication, that the sent token comes from a real app instance by making a request to google services. Google services ensure that the token was generated on a real device (android/ios) and refer to an instance of your app (and not a tampered one).
This is a good way of delegating security issues that I exposed above to google services (who probably are better than you if you're not a security expert).
Of course there are other security measures that you should take to ensure your back-end API integrity. Such as HTTPS, for instance..
So I guess when it comes to mobile development, we should hope for a better solution than that, but since there are no better solutions, using firebase instance id is not bad practice.
Hope this helps
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.
For a quick project for a hack week me and my team implemented Google Sign-In as registration/authentication for users. The way it works:
User signs in with SDK on client (Android + iOS) and requests access_token
Client receives acces_token and uses that token for each network request to the backend as a query parameter
Our backend does not interact with google services on users behalf
The problem I'm facing is that the provided access_token returned by the google SDK is short-lived (60 minutes). That basically leads me to two questions/problems:
Is the short-living access_token even meant to be used that way?
I am used to another flow where you just use that returned token by google or any other auth provider to authenticate with your backend and then use your own authentication mechanism (probably token based as well).
If I am wrong about 1. then what is a good practise to refresh the token on the client side as it expires every 60 minutes. The way I understand it is that Google SDK starts an activity for result to sign in and I would rather want to handle all the networking in my data layer without context. Do I check the validity of that token before I request the backend every time or do I start some kind of refreshing after I get a 401 response back or something similar?
I am somewhat new in that space and I had quite some discussion about what is right and wrong with the backend guy in our team. I'm thinking number one is right, he says number two. I might be terribly wrong here. Some nice input or resources would be awesome as all the documentation online just don't answer both of those questions.
Do one thing use your google provided access token to generate a new access token in your backend and send this token on login/signup to client. Now your every request will use this token to identify users and keep track of everything.
This will not expire too. I used this in my app and it works flawlessly.
I have android app comunicating with api on remote server. I want to make user authentication via google account. I know there's many pages/questions about this topic, but I kind of couldn't figured out which method I need to use.
What I want is, when user registers with his google account, his account will be authenticated and then I want Google to generate some auth token, which is specific for the app and users account. This token should never change, because it should be used on api server to authenticate user.
Do I need to link my app somehow to Google AppEngine or is there any simple solution which I'm not seeing? Or is this method of authenticating completly wrong?
You might be a bit wrong. Cause No one (Not even the Google apps on android) ever get a non expiring token. You Need to save the refresh token and the current token. and after every hour you need to refresh the token using refresh token. And you are good to go (If I have understood your question :P). I would suggest if you already own a server better host the back-end there else GAE works just fine. I hope it helps :)