5

I have a use case where I'd like to create an API that allows users of my Firebase web application to access their portion of the Firebase Realtime Database programatically from a server.

I’ve explored a couple of options, but it would be great to get a recommendation on the best approach to take forward. Here’s what I’ve tried so far:

  1. Using a Service Account - Originally I thought about giving users of my application access to a service account that they could configure on their own servers to interact with the Firebase realtime database. I restricted user's access to only their portion of the Database by setting rules to only allow read/write access on nodes with a particular userId. Giving users access to their userId allowed users to write to their node but no-one else’s. This worked however I think giving users access to a Firebase service account is very insecure and for this reason have now discounted this as a feasible method.

  2. Email / Password REST Auth - I came across this post regarding Firebase Authentication through REST Using mail and password to authenticate via the REST API [Firebase]. I’ve tested the method and it works, so I was thinking I could use this to allow users to use their email and password to sign into Firebase programatically from their servers, create a token using the method above, and then access the Firebase realtime database using the token with the normal REST queries - https://firebase.google.com/docs/reference/rest/database/#section-param-auth. Although I think this would work I know it is making use of an undocumented / unsupported API so would like to avoid if possible.

  3. Wrapping a Firebase Service Account in AWS Lambda - The third option I’ve tried is wrapping a Firebase service account worker in an AWS Lambda function and using AWS API Gateway to create an API that users can call, the user would include their userId in the request and the service account worker running on AWS Lambda would carry out some validation on the request and then make the update to the Firebase realtime database. This is essentially the same as option 1 but hides the service account credentials from the user so I think this would be secure. The downside to this approach is that I will get billed for both the Firebase realtime database calls and the AWS Lambda / API Gateway calls.

It would be great if anyone could advise on the best approach to take or if there are any other options that I haven’t considered!

Community
  • 1
  • 1

1 Answers1

0

I've been looking at solving a similar problem, so bear in mind I don't have first-hand experience implementing a solution yet.

tl;dr: I vote #2.

#1 - I think that, if you could make service accounts work from an authorization/authentication perspective, you'd be adding an entirely new layer of complexity to your app by having to manage multiple service accounts in the Google Cloud dashboard.

#3 - This could actually work fine I think. AWS added the ability to authenticate API Gateway calls, and if you wanted to do a simple auto-scaling Google Cloud Compute (or Cloud Function, eventually), Google Cloud Endpoints look like they'll have the same ability to authenticate requests, though probably way more tightly integrated to firebase auth. You could even abstract away all firebase auth reliance and use API keys, so all your users see is a normal API interface. I think you can set your own uid with the firebase-admin kit, so a 1:1 API Key:Firebase UID mapping could do the trick.

#2 is probably a workaround, but since you've already made it work, it seems like the easy choice. While I do think you're right that it's kind of an off-the-books usage of the feature and could change, it's good enough for now, and recall that premature optimization is the root of all evil :)

Brandon
  • 7,736
  • 9
  • 47
  • 72