I can't seem to be able to implement firebase custom auth. I'm new to programming and I cant find any reference to create custom auth from scratch. My application is android based social report.
the following are my use cases :
I need an admin to manage the data (CRUD the report)
Normal user to post reports
I did some research.
Based on what I've read, I need to create custom auth to differentiate normal users and admin.
I don't know the proper way to implement my auth server. I'm thinking of putting my users data (admin and normal user) on firebase. Is it viable? Do I need to create a separate database of users on my auth server to verify the auth? Can you please explain the workflow of firebase custom authentication?
From the terse description you've given, it doesn't sound like your regular users need custom auth. They can just as easily use email+password or one of the supported social providers to authenticate. Given that you indicate being new to programming and the fact that getting authentication right is hard, I highly recommend not building your own authentication for these users.
Whether your administrators require custom authentication tokens is also debatable. From what you tell about their tasks, they are application administrators: users who fulfill a special role within the application. Those you can easily model in your Firebase security rules. As for regular users, if you can use a built-in identity provider for these administrator, it significantly reduces the chance of introducing a security hole.
Related
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.
Say I'm building some basic not-so-secure Android app, and I want to use firebase as a DB, but I really don't want the user to login. What would be my best choice of authentication?
If I allow "Annonymous" login - will this mean a big security hole, or would it just mean that programmatically I am allowed to change data anywhere in the db?
Does firebase support automatic creation/logging of user using my own custom user/id mechanism (without any user intervention)? Docs aren't very clear about that...
Anonymous log-in just provide authentication, that means you can associate a Unique ID to each of your user.
This de facto create a user ID and a Auth Token that is persisted in the phone between runs of your app. Token is refreshed when you call signInAnonymously().
Check this link for hits on how to handle anonymous logins.
Talking about security, anonymous login is not a bad practice. Obviously if you want to keep your DB safe you have to write custom access rules:
e.g. you probably want "anon_user322" to read your page content, but definitely not to modify or delete it.
Achieving this is not so hard, you have just to go to your FirebaseConsole and write your own rules for the Database.
You can find on this page a good starting guide. I suggest to watch this talk from Google I/O 2016, it is a bit long but you will be able to understand the basic of authentication and security in Firebase Database just with the first 25-30 minutes.
I was using annoymous sign in at first but it has somedown sides like you cannot export and import the exact same user on another device. Therefore i started using password authentication. You can just generate an pseudo email via uuid#yourappdomain.com and also generate the password and keep it within the appdata.
For security purpose you wont get around setting up rules for writing and reading data but it is working quite simple and easy enough to test with both methods annonymous and passoword auth.
i'm creating an android app, which requires some authentication system. I want to have 3 options to log in users: mail&password, facebook login and anonymous access (in case of anonymous i'll create some kind of anonymous account, so user'll be able to give his credentials later and secure his account with 'normal' password).
I'll also have my own webservice for this app. Webservice is in fact the most crucial part and android app will just show data from WS and put some new data on it.
I'll be using Firebase for handling notifications.
My question is: should i use Firebase authentication in this scenario or maybe it's better to stay with own authentication system? If i use Firebase i still need to have users in my database (webservice requires some info about users).
Is firebase authentication good choice for project like that?
Even in the case of Firebase where we use firebase authentication and the firebase database together, only a few details of user(user id, login email or number, provider details etc) are available under the Authentication tab. The rest of the details we receive after login and other custom user information we collect from the app have to be saved in the Firebase database.
So even if you have another Web service instead of using Firebase Database, you can use Firebase Authentication. There are definitely great advantages if you use Firebase Authentication.
Save time on developing Webservice methods for authentication :
Instead, you can just have a method to store user information after the user authenticates with Firebase. Also, there is considerable time saved since you can avoid developing server-side methods for different kinds of token verification in case you want to add social logins like Facebook and Google.
All that will be handled efficiently with Firebase.
Detailed Analytics: Also with Firebase authentication, you can also get good analytics and demographic information of users.
You don't have to use Firebase authentication in order to use FireBase Push Notifications, Invites, etc.
That's one of the beauties of Firebase; you can choose which service to use.
Since everything is built already, I would continue to use your own Auth system
You can save all users, and you can authenticate with Google, Facebook, only email.
It's like a database online and it's easy to connect with the same at Android Studio and after you can login with the users.
I am making android app which authenticate anonymously, so how can i make difficult for other person to discover my firebase url that is accessed from my android app ?
Exposing your Firebase URL is not a big security risk and it is necessary to expose it in order for the users to be able to interact with your database.
To properly protect your data, you should use a combination of authentication and authorization.
The first you'd do through Firebase Authentication, which means you require your users to sign in with the app.
You'd then use this knowledge of who the users are to ensure they can only perform authorized operations on the data. For that you'd use the security rules for the Firebase Database.
If you have those two in place, you can secure the data against malicious users and share the URL without fearing them.
I want to add security to my firebase application so that no one can write data by only knowing firebase url. We are using Android/ iOS client applications and php server.
I need the following to be clarified.
Is authentication using token is the best way to add security (we do not need a user login)
I do not want the token to be expired. Is this possible?
Will this effect read operations from client apps which do not use this tokens?
Can I remove this authentication later so that any one can access
Firebase uses a declarative, server-side rules language to control access to data. This is covered in detail in the security docs. I'd highly recommend reading this before continuing; it would address all the questions here and save some pain later.
Authentication is indeed the simplest way to identify users and control access. Firebase provides a number of authentication methods, including Anonymous auth.
Since security rules can also depend on data stored in Firebase, and use a complex rules engine, it's possible to create any sort of dynamic combination of authenticated and non-authenticated access, role-based security, et al.