Using Firebase as DB for the app only.
I would like to use Firebase to store data that is global for all users. User authentication is not required to access those data.
So, all user's will be able to access same data. For example "news articles" are same for all users. Users don't need to authenticate to access the news.
How can I setup android application to access Firebase data securely for all users?
By "securely", I mean I don't want to bundle credentials to access the DB with the app. Otherwise, anybody can access the data and wipe it or corrupt it.
Based on quick investigation, I found there might be 2 ways:
Firebase REST API
Using Firebase REST API and service account token to access the Firebase data.
Firebase Auth
Use one of the auth schema. For example use email & password auth or custom auth with custom token.
I would assume both of them require me to bundle the secret password or token with the application.
Has anybody designed app with such use-case? Any pointers would be appreciated.
Firebase Authentication doesn't require any bundling of anything. Your users provide their own credentials. Google Play services on the device provides the security that only your app signed with your signing key may receive the token that authorizes the users to perform the actions on the data that you decide through security rules.
Related
I have an app which is already published on the play store and uses some firebase databases whose security rules are public. So in order to make the rules private and fit in the security rules. I would have to implement Firebase Auth.
So my app login flow works as in identifying the user with their phone number OTP verification.
First, I don't want the user to change their login flow. Like I don't want to integrate Social Login.
So is there a way I can use Firebase Phone Auth to my existing flow and get the uid of the user so that in the Firebase DB rules I can use that uid for my auth?
Please help me! I am stuck at this and couldn't find any solution.
If I understand correctly you use a phone number OTP system that is not Firebase Authentication to identify your users.
There is no way to tie that existing flow to Firebase's phone number authentication that I can think of.
The two options that come to mind:
Replace your existing authentication system with Firebase Authentication, and map their new (Firebase) UID to the previous ID system.
Keep using your own phone number verification, and mint a custom Firebase token for your users based on that, then use that to sign in to Firebase. Generating custom tokens can only be done in a trusted environment though.
Scenario:
I want to create an android app which uses username and password for authentication. I decided to use firebase custom auth for that purpose.
From my android app, I am calling a firebase cloud function to authenticate the user with the provided user credentials.
Firebase gives you complete control over authentication by allowing you to authenticate users or devices using secure JSON Web Tokens (JWTs). You generate these tokens on your server, pass them back to a client device, and then use them to authenticate via the signInWithCustomToken() method.
Source: https://firebase.google.com/docs/auth/admin/create-custom-tokens
I would like to make use of firebase firestore to store username and password and use it to create custom JWT for Firebase custom authentication in firebase cloud functions.
Question:
Should I store user credentials in firebase firestore and if yes, what is the secure way to do so. If no, how should I proceed further?
How to create JWT in firebase cloud functions if the credentials passed to the function match with the credentials in firestore.
Note:
I don't have a credential system or own a server.
If you've never created authentication systems before, I highly recommend finding an existing implementation of such an authentication system for your app. Using something that is made by folks that do this for a living, is much less likely to lead to future data leaks that would negatively affect the users of your app.
That said: if you're going to build your own system, you'll want to have a look at this example usename/auth provider in the functions-samples repo. It shows how to receive the data, how to call a backend system, and how to mint a custom token.
For some information on how to store username/password, see Best way to store password in database. Storing this information in Firestore is a common approach, and no better or worse than storing it in any other properly secured cloud-based database.
I have some questions about securing firebase database for mobile applications.
For example, after decompiling Android application a hacker can get firebase api key and then get access to firebase database, is this correct?
Let's assume, I added some security rules like for example an app can read/write on firebase only if auth!=null, this means that the authentication is protecting my firebase database, but this put me to ask the same question, if I configure facebook/google/ or even firebase email authentication I'm gonna need some api keys for those providers in my application, If a hacker got access to those keys, will he be able to use my authentication in his own application and get access to my firebase data?
I want to understand what to do in Android applications to make sure only my application will get access to firebase datatabase.
after decompiling Android application a hacker can get firebase api
key and then get access to firebase database, is this correct?
Only if your database does not use any security rules that limit access to only authenticated users.
if I configure facebook/google/ or even firebase email authentication
I'm gonna need some api keys for those providers in my application, If
a hacker got access to those keys, will he be able to use my
authentication in his own application and get access to my firebase
data?
No, it doesn't work that way.
Each user authenticated with Firebase is issued a token that's used to identify the user when they access protected services, such as Realtime Database, Firestore, or Storage. This token is valid 1 hour and must be refreshed after that, which the SDK will do automatically.
For a hacker to gain control of that user's data, they would have to obtain this token, and they would have no more than an hour to work with it. After that, they would have to obtain the next token obtained by the SDK. All this would have to happen on the user's device.
I have an Android app that allows users to interact with a third-party service via their API. This API makes use of Basic Authentication, so I need the user's username and password for every API call. Ideally I don't want to store the user's credentials locally as this is very insecure. I don't know much about authentication but this is what I think my ideal solution would be:
The user provides their credentials to this service once for verification
Once verified, I send the user's credentials to a backend service to store them, which gives me an auth token. I store this token locally (is encryption important here?)
Whenever I want to make future calls to this service, I use this auth token to talk to the backend service, which provides me with the user's username/password for Basic Authentication to make API calls
Is this a good solution? If so, are there backend services in place that I can use to facilitate this process? I've looked at Firebase Authentication but I don't know if it fills my needs as I'm trying to store credentials for a third-party service, not specifically for my app. I've heard of Auth0 which may be what I'm looking for but appears to be overkill for a small app like mine.
You can easily use Firebase Auth and get all the functionality you need while keeping your users secure. It provides the features you need:
Firebase supports password authentication and properly stores hashed/salted password credentials according the industry standards. This would be one API to createUserWithEmailAndPassword or signInWithEmailAndPassword.
Firebase provides a mechanism to verify email addresses. It is also one API: user.sendEmailVerification()
On sign in, Firebase Auth returns an ID token (user.getIdToken()) which you can use to identify your users in all authenticated requests. They also provide an Admin SDK to parse and verify that token (auth.verifyIdToken(idToken)). A refresh token is also provided to continuously refresh ID tokens on expiration. This means the sessions are indefinite and the user should not need to sign in again on the device.
The ID token provides additional user data like email_verified which you can use to ensure the user is verified. The ID token is a JWT which can't be compromised without the Firebase Auth backend private key.
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.