How exactly do I use a service account (rather than OAuth2) to authenticate to Firebase Cloud Firestore?
The documentation for authentication seems to imply that I can use a Google service account to authenticate to Firebase, but the only type of credential that can be selected from the Firebase Cloud Firestore node is the “Google Firebase Cloud Firestore OAuth2 API”. The n8n docs only document a single “Google API” credential type, and this one supports entering a service account email and private key, but this credential can not be used to authenticate to the Firebase n8n node.
Currently, Firebase and Firestore support just OAuth2. To be honest not sure if those two services can use service accounts for authentication. Will have to investigate.
Thanks for the prompt reply. I can assure you that all of Firebase support using service accounts (as do most of the other Google API’s). I’m already using service accounts to communicate with Firebase, and I suspect that if you simply allowed your existing Google API credential provider to be used on the Firebase node, it would work properly for service accounts.
I’ll give it a try. Upon downloading the source and building it, I see there’s work in progress for Quickbooks and additional JIRA integration which will be useful to me. I’m building a complete asset management solution for my company. Our products all have unique serial numbers that are tracked during manufacturing (AppSheet), sales (QuickBooks Online), customer warranty registration (Google Forms), each time the customer uses our setup software (Google Firebase Firestore), and whenever the customer contacts us for support (JIRA). Our goal is to be able to have the complete history of the product at our fingertips, including, possibly, when the customer calls us (VOIP phone system). Right now, these systems are more or less disconnected, through I’ve got some of the pieces put together. N8N is going to glue all of these into a central asset management database. For now, I’ve opted to host using your cloud solution, but we may stand up a docker container somewhere at some point. I’m happy to provide feedback on any of my experience and share our progress.
The service account authentication works properly as checked in. I downloaded and built n8n from the sources from the feature/firebase-firestore branch and built a simple workflow that dumped a complete collection using the n8n firestore node and my service account credentials.
More broadly, I am not completely clear on why n8n has credential providers for each of the different Google services. Is this a historical artifact of some kind? I would guess that your “Google API” credential provider (which presently only supports “Books, Drive, Gmail, Sheets, and Translate” would work properly for the Firebase case as well, at least for service accounts, and probably for most of the other cases. There are very few Google services that do not allow service account access and while there are wrinkles associated with impersonation, they are usually handled in the same way across the API base. I’ve got more than a casual history with the Google API’s, but I haven’t dug into the n8n authentication code, so this may all be idle speculation.
For OAuth would the problem be that it would always request all the scopes of all the services. So if somebody wants to only use Google Books they probably do not want to also give access to Drive, Gmail, Sheets, … and everything else that exists at the same time.
For the Service Account, it should, however, be always the same. Everywhere where it is implemented like Gmail, Drive, Sheets, … it uses the same one. I personally do not know why that is different for Firebase but I am sure @RicardoE105 can explain why that one is an exception.
More broadly, I am not completely clear on why n8n has credential providers for each of the different Google services. Is this a historical artifact of some kind? I would guess that your “Google API” credential provider (which presently only supports “Books, Drive, Gmail, Sheets, and Translate” would work properly for the Firebase case as well, at least for service accounts, and probably for most of the other cases. There are very few Google services that do not allow service account access and while there are wrinkles associated with impersonation, they are usually handled in the same way across the API base. I’ve got more than a casual history with the Google API’s, but I haven’t dug into the n8n authentication code, so this may all be idle speculation.
Yes, I created a new type of credentials to remove the Inpersonification options. Not sure if this would work with Firebase & Firestore. Should Firebase & Firestore work with impersonation as well? I thought the impersonation options work just with the Google Workspace tools.
If it works with impersonation then I guess all Google Services can use the same.
After a bit of research on my own, I think you are on the right track here. Here’s what I found…
If you have a GSuite domain, then service accounts in user there can be delegated domain wide authority to act on behalf of users. This is potentially true for any service that’s part of the GSuite (now Google Workspace).
It is possible to use OAuth of the two legged variety to authenticate a service account to Google APIs.
Firebase services have a whole federated identity management that includes OAuth, of course, and they can be authenticated by a Google Workspace account among others. It does not appear that impersonation in the classic sense is an available feature on Firebase, though there is [some discussion about it on the Firebase account at GitHub… .See issue 132. You can use [databaseAuthVariableOverride] to simulate accessing the Realtime Database as another user.
Firebase services create a number of Google managed service accounts that provide peering into the other Google APIs and services like Cloud Storage.
I properly attributed this reply with links to the appropriate sources when I first wrote it, but as I new user, I’m limited to two links per reply and couldn’t post it. There didn’t seem to be much point in doing some and not others so I’ve omitted them for now, and I’ve saved the original reply with links if needed.
Is this the only federation support that has been added so far? I’m searching for SAML 2.0 or OAuth in an attempt to build a n8n server that federates server ACL to GSuite, but I’m seeing next to nothing other than basic auth support.
Hi @kimowasabiii It looks like that didn’t get merged, in the end. Could you head over to our Feature Request section of the forum and ask for this to be added there? That’s a forum section our product team most regularly monitors!
It looks like that didn’t get merged, in the end. Could you head over to our