I've used firebase authentication for my react app.But later many people said that firebase authentication is not much secure and they suggest me to go with JWT authentication or passport.js authentication methods.
But I don't want to shift from firebase because of its simpleness.Now I'm thinking to use google authentication signIn method in firebase. Is google authentication in firebase is also not safe? Is it safe to opt google authentication in firebase?
There is nothing particularly "unsafe" about Firebase Authentication, especially compared to other options. If another options meets your specific needs better, then go with it. But without specific details on what you think to be unsafe about Firebase Auth, there is nothing really to say.
Related
This is a follow-up question from Firebase Multiple Accounts are signed at the same time
So, I want to create a web application using Firebase Authentication, where a user can switch between multiple accounts. The solution to that problem is linked here: https://stackoverflow.com/a/55905698/16925281
From the provided solution, we can get the Firebase credentials for any account and use it to switch. However, how can I safely store the said credentials at Client Side (Preferably, in ReactJS)?
can i use JWT in firebase firestore for my react app. If possible how do i use that. I know firebase have firebase auth. But just wanted to use JWT.
Please detail.
React or Angular is totally independent of what authentication you use. Even if you have no authentication they don't care.
To use FireBase JWT auth, you need to,
have a front end login page to collect credentials from user
Firebase will give you Javascript necessary to call firebase from your React application, embed that code. When ever anybody visits your site, make the user put in login credentials
Through those credentials using the javascript library to firebase APIs so you get can get the token if credentials are okay
deny login to enduser if the credentails are not accepted which you can know based on the result of API (invoked using that javascript provided)
if valid token is returned, store it in session storage and use it throughout the application (token itself contains the signature) to verify if the login is legit or not.
Hope this helps
I have seen a similar question like How to solve API key is visible on request URL problem?, but I don't think it's applicable to my use case.
I'm using Firebase authentication for my application (React app, served from NestJS back end) and notice one thing, it exposes Google Cloud API key via request URL. The current authentication flow is:
Using OAuth2, the front-end makes a call to Google Identity Platform using Firebase SDK to retrieve login information (display name, ID token, etc.)
The front-end makes a call to NestJS API to validate the login information using Firebase Admin SDK and create HTTP only cookie to preserve authentication state.
As far as I know, the React App requires access to API key so Firebase can be implemented. There is no way to bypass that requirement. Even if a key is hidden in .env file, the API key is still revealed via network tab. In some cases, let say if I forget to handle exception of a signInWithRedirect() (or any other Firebase functions), the error is raised (Uncaught Promise: requestUrl/apiKey="My Key") is shown in console, so it's even worse.
I'm not certain if I misunderstand something regarding the whole implementation and authentication flow. If it is, then please correct me on that. If not, please let know how to solve this issue.
It appears in the case of Firebase, exposing API key is fine. However, this is only due to how Firebase works, not because exposing API key in general is safe. A more detailed discussion can be found here: Is it safe to expose Firebase apiKey to the public?
I'm using Google Identity Platform, not Firebase, but Google Identity Platform uses Firebase and Firebase Admin SDK too so I believe this is applicable.
This matter is also mentioned in official Firebase instruction video. Kudos to user usr28765526 for mentioning this.
Im watching this tutorial that uses the firebase client library in cloud functions to authenticate users. I am starting to doubt wether this is the right approach. Should I do all the authentication in the react app instead? The tutorial explains that the benefit of doing everything server side is that it decreases the amount of things the user has to download to run the application.
That being said, Im having difficulty getting the client library to work with typescript which makes me just want to scrap it. How should I proceed?
It is generally better practice to host authentication (and especially authentication logic) in the back-end, if not for performance, definitely for security reasons.
That said, you can avoid using cloud functions for this authentication with firebase! Here is an alternative super simple video tutorial you may like instead from Fireship: https://www.youtube.com/watch?v=zQyrwxMPm88. The Google Firebase YouTube channel also has many videos on the subject.
Cloud functions are useful for when you want parallel action to be taken in the back-end during or after login, while the useAuthState() react hook is great for when you want parallel action to be taken in the front-end during or after login.
so my view on the best approach to solve this on Firebase is to either:
A) Use the Auth Firebase SDK for your client to create users and sign in users,
B) Do it with the Auth REST API
The end result is the same, you get your users into Firebase and you can sign them in and get their auth tokens. The SDK runs on the client, the REST API runs on the server. Once that's done, you can use the user token and pass it to cloud functions to do whatever you need and check the token validity and permissions server side.
On the cloud functions you're supposed to use the Admin SDK, not the client SDK. And the admin SDK has all privileges. For a more specific reason why you SHOULD NOT use the client SDK on cloud functions, is because it keeps state. So 2 users calling your cloud functions, using the client sdk server side, would result in the same user token, which is an error.
I hope I've solved your problem?
I am deciding which technologies to choose for my next project and I've decided that I'd like to use some of the Google Cloud products. I've been reading about Firestore in Native Mode and the idea of developing a web without a server need for CRUD operations seems really interesting.
My problem comes with me wanting to also use Google Recaptcha v3, is there any way to read how trusted an user is using according to Recaptcha v3 in the secutiry rules of Firestore to deny the request if it's, for example, under 2.
Thanks
No, Firestore security rules don't have any access to data from recaptcha. If you want to know something about the end user, you will have to use Firebase Authentication.
There is no information about Google Recaptcha v2 that is automatically included in the Firebase Authentication token for the user, as far as I know. And since the auth token is the only information about the user that is available in security rules (as request.auth), the repatcha information won't be available.
The only way to get that information into the user's token is if you'd add it yourself as a custom claim from one of the Admin SDKs.