I am building a react native mobile application, and I'm using the expo Google and Apple sign in libraries to provide authentication. Both libraries use firebase to authenticate, but my database is hosted elsewhere (heroku while in development, but probably migrating to digital ocean in the future). How can I protect my API using the access tokens I receive from the Google and Apple sign in utilities on my non-firebase server? All the code samples I've seen use firebase as the backend. I want to make sure that all the API calls are authenticated, and that the proper storing/refreshing techniques are used on the client, while maintaining the "persistent session" UX for users so they don't have to sign in every time they open the application.
I feel like I should know this, and I have a few ideas, but really don't want to get this aspect of the application wrong.
Related
BACKGROUND INFO
I have developed an application in R through the shiny package, and deployed it online through the shinyapps.io service.
Among its different functions, the shiny app can send emails (through my personal Google Account) to users if the fill a form. The emails are sent through the functionalities of the gmailr package, and to make it work I had to follow the procedure on the Google Cloud Platform to create a JSON token, configure the OAuth consent screen, and store the credentials I obtain in a folder of my R project. All the steps to this process are reported at the end of this GitHub issue I opened a while ago.
THE PROBLEM
The JSON token I generated on the Google Cloud Platform expires after some days.
After googling around, I noticed that this can happen if my "Application", on Google Cloud, is still in the Testing phase. First question about this statement:
What does it mean when Google refers, on the OAuth screen, as an Application in Testing phase? My application is already online on shinyapps.io, it's already functioning, and when I create a new token it can also send emails correctly (for a while).
In addition, on the Google's OAuth consent screen, I now have the possibility to "publish" such application. If I do that, the status changes as In production, and this message is displayed. Other questions:
What does it mean that the application will be available to everyone with a Google account? My application deployed on shinyapps.io doesn't require any login or any other data from the users, then what is this app they're talking about?
What will happen to users that try to connect to my application?
Are my credentials, as for example the JSON file, safe?
I know that there might be a lot of confusion in this post, but I am relly not an expert in this field, and so I am worried to make some mistakes.
Thanks a lot for your help!
The GMail API, OAuth and all, is typically meant to allow your app to send email on behalf of any user. It seems your use-case is a little different - you only ever need to connect one user: your own.
What does it mean when Google refers, on the OAuth screen, as an **Application in Testing phase? My application is already online on shinyapps.io, it's already functioning, and when I create a new token it can also send emails correctly (for a while).
I think you mostly answered this yourself in your further questions. Google thinks you're building an app that any GMail user can connect to, and so for security reasons, they want to differentiate between a test app and a production app. They don't necessarily know whether or not your app is published on shinyapps.io.
What does it mean that the application will be available to everyone with a Google account? My application deployed on shinyapps.io doesn't require any login or any other data from the users, then what is this app they're talking about?
I alluded to this earlier, but the GMail API is intended for apps that allow any GMail user to connect and manipulate their own email. Imagine a third-party email client, or similar. Again - Google's wording sounds a bit odd wrt your app since it doesn't fit that bill.
What will happen to users that try to connect to my application?
If you don't explicitly host your own server that implements OAuth with Google, then nobody can even try to connect. As long as you don't leak the shared secret from your Google Cloud Platform entry, you're safe.
Are my credentials, as for example the JSON file, safe?
Probably anyone with the JSON file can send email on your behalf. Marking your app as 'in production' will not change the security implications of your JSON file.
Unfortunately, Google has pretty tight security around their APIs nowadays. If you want to mark your app as "in production" you might open up a can of worms regarding "restricted scopes" (sending email counts as restricted). However, since you're using the JSON file instead full OAuth, I'm not sure if this applies to you. To my knowledge, you should be safe to try marking your app as "in production". Worst-case scenario, you might be able to weasel around the strict verification requirements by saying your app is "internal":
Internal Use: The app is used only by people in your Google Workspace or Cloud Identity organization. Note that your app will not be subject to the unverified app screen or the 100-user cap if it's marked as Internal.
I have a Node.js API (built with Express.js) hosted on Firebase Cloud Functions and an accompanying web application hosted on Firebase Hosting which is supposed to interact with the aforementioned API.
I would like to restrict calls to the API so that only the web application would be able to call the cloud functions. How can I achieve that?
What I have tried:
using the App Check or more precisely Google's reCAPTCHA v3 for web apps. I have whitelisted the domain of the web application and have activated App Check token validation server side as well. The problem with App Check, however, is that I am able to obtain the reCAPTCHA attestation token from the browser (after authenticating through the web app) and use that with requests made from anywhere. This enables bombarding the API from outside the web application and defeats the purpose of using App Check in the first place.
Something to note here, the documentation for activating App Check in Cloud Functions instructs the usage of functions.https.onCall(). However, since my API is built using Express.js, I had to use a workaround to be able to use functions.https.onRequest() as instructed here.
restricting the Cloud Function from Google Cloud console to allow only clients of the same project to call the function as instructed here. Unfortunately, my web application hosted on Firebase Hosting does not seem to belong under the same Google Cloud project. Apps hosted on Firebase Hosting do not appear in Google Cloud console. Furthermore, after adjusting the Ingress settings of the functions to "allow internal traffic only", I am receiving CORS errors when attempting to access the API through the web application. I am unable to access the API from anywhere else though, which is partly the desired outcome.
Before anyone proposes limiting the domains in CORS options from within the API, while this might serve the purpose of restricting access to the API endpoints, it still would allow calling the function rapidly and thus, potentially, racking up the bill.
I am grateful for any suggestions!
Firebaser here.
This is a great question! Doug has already made some great points above, and I'll just add to that by saying that the TTL on App Check tokens reduce the replay window that you observed in your first bullet point, and this TTL is configurable.
The default TTL for reCAPTCHA v3 is 1 day to protect against running out of quota, but you can set a shorter TTL to increase the cost for an attacker trying to set up a replay attack. But please do be mindful of the associated trade-offs as described in the documentation. You can read about the associated quotas and limits here.
Unfortunately, web applications redirected from Firebase Hosting can't hook up to the GCP internal network. App Check is actually exactly what you are looking for in this situation.
Finally, because we are continuously working on improving the App Check platform, the comments you leave here are valuable for us as we decide on what anti-abuse features we want to work on next.
I'm building a production hybrid mobile app that uses Firebase/Firestore. Since it's a hybrid app, I can not use the bundle ID or HTTP referrer methods to restrict the API key (Google support confirmed this is not supported).
My worry is that anyone could decompile the app and get the API key, using it with a simple Node.js script locally, and access my database.
Node.js scripts can bypass all Firestore rules, making unrestricted API keys very powerful. So far I have been unable to find a way to restrict keys with hybrid apps, including reaching out to Google support. I'm wondering if the only way to actually achieve firebase/firestore security is to use Native apps vs. Hybrid?
Actually for ios, we are not able to restrict the google api key. But, for android we have done with HTTP referrer method only.
For android it is possible.
If you are using ionic4, Please use the same origin value whatever you set in you config.xml corresponding to you android app.
I have been working on a web app and I am now looking into hosting said app. This app is a client-side app for right now meaning that all of the work is being done on the clients device and it has no backend other than the web server giving the site to the user for the first time.
I was looking into Heroku but that seems expensive for my app. Then I looked into Firebase Hosting and it looks good but requires the site to have static content. For now I'm pretty sure my app fits that criteria but in the future I would like to have users sign up for accounts and then store the info they give for the app data in a database. Would do database calls to a firebase database make the app non-static/dynamic anymore?
I know I could use Digital Ocean or another server provider but I want to be able to have scaling done for me so I can just focus on the app and not the containers themselves.
It sounds like you might want to build your app with Firebase Authentication for user logins, store data in Firebase Realtime Database, and host all the content on Firebase Hosting. You could probably write the code entirely in JavaScript to run in the browser, but if you did need to write some code on the backend, you could use Cloud Functions for Firebase.
I am trying to create a REST API for my app using Firebase Cloud Functions. I know how to use Admin SDK in Cloud Functions. It does have API to createUser. My front end app lets users sign in using Google and Facebook but I am not sure how to put it all together.
My app has successfully implemented Sign in with Google and Sign in with Facebook but how and what data do I transfer over to Cloud Functions (or any REST API Server for that matter) so that it could create a user in Firebase with appropriate provider.
Update for more explanation
I am creating an app for iOS and Android with some sort of cloud based backend. Right now I am experimenting with Firebase but I do not intend to tightly couple my apps to Firebase and hence do not want to pull Firebase-iOS and Firebase-Android SDKs into my app code. I want the ability and freedom to switch my backend over to AWS or Azure without changing frontend code.
The one (and only?) way is to create a server that will expose REST API endpoints and do the work on my behalf that usually SDK does. To achieve this, I am using Cloud Functions but that shouldn't matter as long as I have API to talk to actual cloud.
After putting that explanation, now my question is how do I let my users login to app using external providers like Google and Facebook and still achieve what I am trying to do. When I let users sign in with providers, I do not have their password to send to backend to create a new email/password user.
The sample code that best illustrates what you want to do here on GitHub.
It shows how to create an Express app that handles HTTP request pages. Learn more about Express to configure it for wildcards are needed.
It accepts and checks authentication tokens in HTTP requests from Firebase Authentication to validate the end user responsible for the request.