By Lo Ferris, Developer Relations Engineer
Since its launch in 2011, Firebase has become a compelling resource for rapid development for mobile and the web. A leader in the increasingly popular Backend-as-a-Service scene, Firebase is the backbone of a current generation of apps in the “serverless” movement. Firebase provides, among other things, several different options for realtime data storage as well as modeling, hosting, and robust social authentication for user-management. Since its induction into the Google Cloud Platform ecosystem, Firebase offerings have become increasingly powerful and complex.
As startups have grown with their Firebase integrations, they’ve looked for ways to take their existing architecture with them as they move up-market and close enterprise deals. Firebase fans have been asking, therefore, how to implement enterprise features such as Single Sign-On in their products. We’ve come across many variations of this scenario internally and “in the field," for example:
And the answer, across the board, is that although there are no out-of-the-box solutions for Firebase SSO, especially for enterprise IdPs, there is a custom route, which can take various forms.
Since Google acquired Firebase in 2014, it has pursued an ever-shifting balance between incorporating and “promoting” best-in-class features from Firebase to other Google Cloud products and supporting the growth of a development platform with its own unique ethos and brand-identity.
The original Firebase Authentication, a core product, still exists in parallel with other Google Cloud Identity solutions and supports several social logins, Google OAuth being the easiest and most flexible. Most Google Cloud Platform products can be incorporated to varying degrees into Firebase apps, so the integrations within the GCP are quite powerful!
Recently Google released their Cloud Identity Platform, which allows for broader user management across the GCP and now offers enterprise offerings, including SSO. Therefore, one “native” way to incorporate SSO into your Firebase app is to migrate your users to the Cloud Identity Platform. This process still involves a fair amount of manual work, but it is an intriguing and promising option for GCP connoisseurs. This migration, as of writing, however, remains more or less an uncharted path.
Fortunately, while Google continues to invest in deepening the interconnections within their own ecosystem, Firebase still supports custom third-party auth integrations, which provide the groundwork for many different SSO solutions.
Because the Firebase Admin SDK has the ability to generate custom tokens, there are several different ways to incorporate SSO into your app, which vary in labor-intensiveness. All the Firebase admin API needs is a confirmed user login: how you get this authentication is really up to you!
Now, it’s unlikely you’d pass anything other than a unique piece of information that proves your user is authenticated by your IdP. The most common use case, and the most relevant, is for this identifier to come from confirmation that the user has been authenticated by your IdP: that is, with a token. The simplest way to increase the flexibility and enterprise capacity of your Firebase-powered apps is to orchestrate your own “token exchange.”
Your IdP integration, of course, can be as complex as a roll-your-own system you build in-house or as simple as a few lines of code. The exchange itself will depend on the framework and architecture of your app, but the best way to think about it is as a “microservice” that can be integrated into your business logic in a way that makes the most sense.
Firebase has even highlighted popular identity providers and SSO in their own guides, such as Okta. Firebase’s Okta’s guide, in fact, was a big inspiration for our in-house solution! The WorkOS solution is not unique, and you should be able to apply these principles elsewhere, but it does benefit from having a very small code footprint - our calling card!
Our recipe for Firebase + WorkOS SSO assumes you already have a Firebase client ready to go. Although our demo app for this post is written as a standalone microservice, feel free to incorporate the logic for your custom token exchange wherever you’re defining your routes for logging in. (We’ve also included some starter code for Go and Python as well in our guide. The first step in this process should be familiar for everyone who’s worked with our SSO before - if not, check out our SSO Guide first! The basic flow for a WorkOS login in Express, for example, would look like this:
Now it’s time to incorporate Firebase, which should also look pretty familiar for those already working with the Firebase Admin SDK. If not, check out this handy guide from Firebase! In our demo app, incorporating the Firebase Admin SDK would look like this:
Finally, it’s time to put them all together! Our token exchange will take place in our “callback function," which we trigger upon a successful login attempt via WorkOS. This will create the token out of a user’s WorkOS profile id and send that token to your Firebase client.
Then, you can authenticate users client-side like so:
If you’d like to see a full version of this microservice, check out the repo on Github.
WorkOS engineers love how each new startup we talk to inspires us to create custom, no-fuss solutions for everything on the typical enterprise-ready wishlist. Firebase is a great example of a platform that allows for customization in addition to its native ecosystem solutions, which is part of why it has so many fans! We’ve relished the chance to dig in and set up our own recipe for a custom Firebase SSO solution, and are excited to show you what we’re cooking up next. Remember, we take requests!