How to secure an apollo server that is being used by a meteor (with no mongo) client?
Currently the meteor security relies heavily on mongo to manage users, generate tokens, but due to price concerns and setting a mongo instance on a scalable server is a no go, mongo was dropped, now the question is how to replace it or make meteor security connect to a graphql server?
Meteor user security relies on MongoDB, so if you don't use MongoDB, you can't get Meteor user security.
You can get general user security through manual checks in your resolvers. See the GitHunt example's user accounts system:
https://github.com/apollographql/GitHunt-API/blob/master/api/githubLogin.js
and it securely looks up the current logged-in user with eg
https://github.com/apollographql/GitHunt-API/blob/8dc58240ec00be227848f1054535ac47c6dc46b2/api/sql/schema.js#L85
Related
Do any of the Firebase Node/JS SDKs support making calls to Firestore from a node server or cloud functions (e.g. nextjs, remix) on a users behalf, respecting security rules for the authenticated user and supporting sessions for multiple simultaneous users?
Use case:
I have a mobile application with Firebase Security rules set up. I want to serve the same data from a server side web application without reimplementing the Firebase security rules on the web server and keeping them in sync.
e.g. if a user requests a post by id, and Firebase rules prevents them from having access to that specific post, I want Firebase to tell me that and for the web server to forward the 403 status to the user.
More info:
I read this:
If you are developing a Web or Node.js application that accesses Cloud Firestore on behalf of end users, use the firebase Client SDK.
Which suggests this should be possible, however my understanding is that:
firebase-js-sdk can only have one user authenticated at a time so would not be safe if handling async calls from multiple users at once
firebase-admin can be run as a specific user, but this can only be done during initializeAdminApp and again would affect all requests that are currently using the firebase-admin import
Is that correct? Are there any other ways to act on behalf of the authenticated user from a web app?
The only thing I can think of would be the REST API…
https://firebase.google.com/docs/firestore/use-rest-api
Do any of the Firebase Node/JS SDKs support making calls to Firestore from a node server or cloud functions (e.g. nextjs, remix) on a users behalf, respecting security rules for the authenticated user and supporting sessions for multiple simultaneous users?
No, the backend SDKs always bypass security rules. Only the web and mobile SDKs that you use inside the client app make use of authentication tokens available from the user's prior sign-in.
You could consider using the REST API instead since it allows you to pass through a client auth token. It will be up to you to manage the transfer of that token manually.
Several questions have asked to run the firebase-admin package in the browser, such as
Can I break the rules and use firebase-admin on the client side? Or will trying to workaround errors be for nothing?
How to properly use Firebase Admin SDK using Node.js for a web-app?
Error importing firebase-admin
https://groups.google.com/g/firebase-talk/c/Jfq054TLEFQ?pli=1
However, both the questions and the answers given do not properly distinguish between the "browser vs. server/backend" distinction and the "end-user vs. privileged" distinction. A common theme seems to be warning against opening up firebase-admin for end-users, which is obviously a security risk, but they do not explain why a privileged user cannot access privileged Firebase functionality from code running in the browser, only from a backend / server.
So, assuming that a user has sufficient privileges (say, firebase project owner) and is willing to perform whatever authentication needed to transfer these privileges to code running in the browser -- what reasons are there for not doing this? Will it not work? Are there security risks? Is it simply discouraged because a significant fraction of developers will make mistakes WRT the exact requirements for making this work securely?
I think you have a misunderstanding about what a "privileged user" is, as you say.
firebase-admin is initialized with a service account. This is not the same as an Firebase Auth user account. Service accounts are entities belonging to a cloud project that are granted privileged access to some resources in that project. This is how fireabse-admin operates - you init with a service account and gain that privileged access. firebase-admin does not init with a user account.
You never want to expose a service account credentials to a web browser. That's a huge security risk. Since firebase-admin requires a service account, you will never want to use firebase-admin in the browser where it will be seen as public information.
The whole point of the documentation on the matter is to get you to write code to send Firebase Auth user tokens to your backend, where you can safely validate them and decide if that end user should be able to perform privileged operations using firebase-admin. There is really no safe workaround to this scheme - this is the pattern you should follow.
I'm developing an android app with firebase as a backend and I heard a word named Admin SDK. I had searched for it and found it is used to manage data.
But I have a doubt that firebase provides a console webpage (console.firebase.google.com) to manage data, but why there is a separate Admin SDK?
Can someOne please explain...
The firebase admin SDK provides a simple and easy way to modify firebase settings and data using API calls.
For example, you might ask: why should you even have a regular SDK to store data? After all, you can store and save data directly from the web interface. It is, however, simply not secure or practical to have users update their own data each time using the console.
Similarly, the admin SDK is just like the regular SDK but with administrator permissions. For example, it allows you to bypass the rules set up using your firestore rules. The Firebase admin SDK is meant to be used on your backend - so you know it is running trusted software. You know that it will act the way you expect it to, unlike code running client-side that can't be trusted.
For example, let's say that you want to be able to delete a user's post if certain conditions are met. The user will make the request to your server, and it will check if the conditions are met, and then delete the post using its admin privilages. Sure you could technically automate this using firestorm rules, but those can be quite cumbersome and might not work in more complicated examples.
You can also even use it to integrate with other applications like connecting your app to a moderation tool or a curse detector that can't or shouldn't run on the client's device.
Is your question is why does Admin SDK exists?
There are several administrative tasks such as deleting users, listing collections and many more which the client cannot and should not be able to do.
Firebase Admin SDK has admin access to your Firebase project's resources.
It does not obey any security rules and can read/write any of your database, storage bucket..
That is why you must use Admin SDK in a server (or cloud function only). Although I feel Firebase Admin SDK is more useful if you use your own servers and authentication method. If you are using a custom server then:
It can be used to generate custom token so you can authenticate users using your own method (maybe legacy auth system) but still use Firebase Authentication to handle the auth tokens thereafter.
If you use your own database (and not any from Firebase), the Admin SDK can verify the ID Token sent by client and get identity of that user. Thereafter it's could be a simple if-else statement for you to decide if the user has access to the request resource or not.
I implement user signup logic in my nodejs backend server. It uses firebase for username and password signup. Below is the code used in nodejs:
var firebaseClient = require('firebase');
firebaseClient.initializeApp(config)
firebaseClient.auth(). createUserWithEmailAndPassword(req.body.email, req.body.password).catch(function(error){
console.log(error);
})
the problem for this approach is that firebase has a usage limit which is 100 accounts/IP address/hour. All users who signup in my application will go to my nodejs server first. That means firebase will think there is only one user. It will meet the usage limit very easily. I know I can put the signup process in the frontend but I don't like doing this. Because my signup logic needs to save something in my local database as well. I wand them to be in one place. Does anyone know how to handle the usage limit in my case?
The Firebase-Auth AdminSDK should not be rate limited so you can use it on your NodeJS server without any problems to handle as many user authentications as you require.
Make sure you don't use the client-side javascript SDK, which should not be used on the backend, but instead for frontend consumers like IoT, WebApps, Consumer Desktop Apps..
More info on the difference here: https://firebase.google.com/docs/admin/setup
I am considering to migrate an application to Cloud Foundry since I'm tired of managing my server on my own. In my current application I use Spring Security and sessions to handle my user logins. I am however clueless on how to change my code so Cloud Foundry's multiple instances support my user logged in in a somehow stateless way (but using a token). I have looked into UAA, but it seems that this is for cloud foundry users, not users of my application.
Something OAUTH2-like seems to be a solution, but it seems I would have to rely on third parties if I want to do it in a developer-friendly way. The Cloud Foundry (or Pivotal Web Services in this case) documentation is also quite unclear on the matter.
When looking at the Spring Cloud documentation, I do find information on how to use OAUTH2 providers like Github to do things like Authentication, but it doesn't show how to actually use the Principal or how to handle stuff like Authorization (role-based).
I assume there are ways to run my own OAUTH2 service, and that would be the recommended solution, but again, there's quite a lack of documentation.
Can anyone give me some pointers?
A couple of key questions here are where is your user store currently? And what do you want to do with it moving forwards?
If you manage your own users and wish to continue doing so then, after migrating your users to the appropriate backing service and updating your app to be able to bind to that service using CFs VCAP_SERVICES env variable (also see spring cloud), our session affinity should allow you to push your app pretty much as-is. Otherwise a little further discussion is required.
Does this help:
https://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#sessions
Cloud Foundry supports session affinity or sticky sessions for incoming HTTP requests to applications if a jsessionid cookie is used. If multiple instances of an application are running on Cloud Foundry, all requests from a given client will be routed to the same application instance. This allows application containers and frameworks to store session data specific to each user session.