Streaming live at 10am (PST)

Webflow integrated with FirebaseUI for user authentication


@andrewrubio Hey Andrew, thanks for the feedback. Makes it all worthwhile when I can see people getting some real value!

To answer your questions:

Question 1:

When I have elements on the same page where I want some to be visible if the user’s info meets certain criteria (from the database), and some elements visible for other users, the elements seem to appear or disappear in a flash just as the page loads. You can see this on the homepage for example. The way I’ve done this is through hiding the elements by default and applying jQuery to show the elements if the user has the correct fields in their user record. Is there a smarter and faster way to do this?

This is happening because you have set the buttons to display “block” or “inline-block” within the webflow designer. This is the css equivalent of doing something like:

 .btn-login {
    display: block;

So what happens is that when your page loads, the CSS style has already been set to display “block” or “inline block”. This is set before your scripts which hide and show buttons depending on your user’s authentication state have a chance to run. This script takes a few split seconds to run after the page loads, so this is why you briefly see buttons that you shouldn’t.

To fix this, you can do a bit of a dirty Webflow hack that works. You can just set all your buttons that needs to be either shown or hidden to “display: none” from within Webflow. The downside to this is that you won’t be able to see them in the editor and it will just look weird.

What I did was add a custom CSS tag to my buttons in Webflow which I simply called “hide”. Then in the site wide head code, in first place before anything else runs I wrote a custom style tag:

 .hide {
    display: none;

This way, when my page loads, the buttons for which I want to set visibility depending on user authentication state are not visible until my script has a chance to run. It also allows me see my buttons in the Webflow editor.

Question 2:

How would I be able to set up paid subscriptions? I know you’ve mentioned it in your original post but it’d be great if I could somehow integrate this. The use case here being a monthly subscription that they pay through a direct debit for updated monthly content. Ideally this should be done during the sign-up stage.

I am actually building a demo site right now where I am doing exactly this. The short answer is that yes it’s entirely possible, but at the time of me writing this you can’t do it with FirebaseUI. FirebaseUI is an excellent solution that is very easy to get set up and running with, but it does have limitations. For example, there is no way to set user roles (admin, premium user, free user, etc).

To do this you must generate your own custom authentication tokens, and only then can you add custom “claims” (Firebase jargon for user roles) to these tokens. On your Firebase database, you can then check the claims in a user’s token when they try to read or write to make sure that they have the appropriate user role to do so.

Stay tuned as once I have finished my demo site I am going to make a new screen cast series where you can follow along as I set this up and see how its done.

Question 3:

Is there a way to influence the filters on a Collection list by using data from Firebase. For example, in a collection list you can say “Return me items between 10 and 100” - can the number 10 here be filled in dynamically depending on a field of the current user: e.g. CurrentUser’s “monthsPaid” = 17, therefore show Collection list from 17 to 100.

In short, I don’t know because I have never tried. Webflow kindly gives you API access to their CMS system, so it is probably possible to do something like this. If there is much demand for tutorials on how to integrate Firebase with the Webflow CMS then I will do a new screen cast series and show people how to do it. Assuming I can get it working myself, of course :smiley:


Hey @jasondark thanks for your super quick reply. I’ve just done it the way you explained for the Question 1 and that works a lot better. One thing I’ve noticed is that when I log out, the elements for “non-logged in users” appears for a split second before you are redirected because of the code that adds classes to elements if a user is logged out. I guess this is because firebase.auth().onAuthStateChanged(user runs continuously?

To do this you must generate your own custom authentication tokens, and only then can you add custom “claims” (Firebase jargon for user roles) to these tokens.

It’d be great to see how these tokens are properly created in Firebase - please let me know when you have a tutorial/video available for this! At the moment, what I’m doing is setting a new custom field for each user like “membershipType” and defining that on sign-up. Then for some elements on pages (or entire pages themselves) I’ll only show if their “membershipType” is a particular value. But the tokens you’re mentioning sounds more legit.

Can’t wait to see how we can integrate with the CMS too! I’ll try give it a go myself too.


This “glitchy” behavior happens because your log out function does not explicitly force the user to be redirected to another page. Instead your log out function runs, and only a split second later does your firebase.auth().onAuthStateChanged(user) function recognise that something has changed.

To fix this, add a step into your log out function that redirects users straight away. Use something like location.href().

But please read this!!!
What you’re doing with setting membership types is not entirely wrong, but all your security is relying on the front end. In a real world app this is incredibly unsafe and please don’t do this.

For example, what’s to stop me from just inspecting your website, familiarising myself with the code, then modifying it to bypass your front end guards? I could easily remove a line that says something like “only allow users who have the “paid” value set for the “member” key in their user folder to see this page”.

This front end piece is great for providing a nice user experience, but it is not security. With Firebase, real security is done on the back end when Firebase verifies that your user token has the right claims for what you want to read or write. For example if you wanted to allow only admins to read or write to a folder, this is what the database rule would look like:

  "rules": {
    "adminContent": {
      ".read": "auth.token.admin === true",
      ".write": "auth.token.admin === true",

Take special note of this line ".write": "auth.token.admin === true". This is Firebase checking that your token contains the right claims. This is a secure way of doing things because the tokens are securely generated by Firebase.


@jasondark awesome that makes sense. I did already have a redirect in place but commented it out to test since I saw the elements flash into place just before the page redirected, but I’ll work something out.

Also good point about the security - I did think about that and it felt incredibly unsafe to have a lot of the restriction functionality done through the front-end.

Keep us posted on when you have a demo of the tokens working as I’m keen to get this working in a more secure way! Thanks again.


I noticed in looking at your source code that the API key for firebase was available. Is there an elegant way to hide this type of information. Knowing that there is no webflow server to do this are there any other ways?

I suppose this question would apply to a whole host of possible API integrations.


Great question Drew! When I first started looking at using Firebase this concerned me too. However putting the key directly into your html head is exactly what Firebase documentation tells you to do. At the end of the day, the client needs access to this key to talk to Firebase - so it has to be present on the client.

So what’s to stop just anyone from grabbing your key and making requests to Firebase? Nothing really, but whether or not Firebase responds to requests is up to you. Within Firebase, you can go to the Authentication section and add only the domains from which you want to accept requests. You simply whitelist the domains that you trust.

This means that to be authenticated, a user must have come from a trusted domain. Next to actually secure your data, you set a default rule that only allows authenticated users to read from your Firebase Real Time Database / Firestore.

This way you can be sure that

  1. If a user is authenticated, they came from a domain you trust

  2. To actually read your Firebase data, a user must be authenticated

If you wanted to make it a little harder for someone to see your Firebase config, you could look at loading it via a http script include in your html head. This way at a first glance you would only see a script include, however there would be nothing to stop someone from simply going to the url of your script and seeing the Firebase config.

I hope this clears things up.




Is it possible to allow users to embed their custom fields stored in Firebase into another website? For instance, a user signs up to my database under category “house hunter”, and then fills out the fields to populate the real estate listing complete with photo.

Is there a way that I could allow them to grab it via an iframe so they can still the listing in other place on the web?


If I understand your question correctly then yes, this would be possible. Some more detail / context would be helpful. If you want to embed an iframe containing data on another site for anyone to see, your database rules will need to change to allow public read access to this data that your users would set from within your site.


You’re right, the term I was looking for is “public read access”. So to add more context what I’m looking at is how to achieve something like YouTube’s share functionality where you can grab the embed iframe and stick it in another site/blog.

In this case, User signs up, has a number of fields they can enter with data, and then can click a share button from within their user account that generates an embed for the new data which they can share freely.

I wonder how one might implement that.

Thanks for the awesome guides!


@jasondark Absolutely fantastic thing you’ve got going here!

I’ve tried and tried to get something like this working myself but this looks like a great solution. I think the reason for my trials not working is that I have tried to make everything quite custom (even down to the forms that users are to log in with).

For me I’d like to see more tutorials on:

  1. Customisation, moving away from FirebaseUI
  2. Utilising the Webflow API to get Firebase data into Collections. This is a huge one for me as I want to build an app that users can add/edit records in Firebase. Using Collection Lists and Pages would be a massive leap forward.

Great job, can’t wait to see what you bring out next!


@jasondark I’ve managed to create a VERY basic custom log in/sign up site here:

This uses a couple of basic scripts to allow us Webflow users to create custom log in and sign up pages rather than rely on Firebase UI.

Preview this site in Webflow to see the code I used on each page:

It’s certainly not perfect, it will need some code clean up and form validation to make it even better.


Hi Jason,

Thanks for getting back to me with some things you would like to see. The points you mention seem to be reoccurring themes so I will likely make these the focus of future videos.

Since my first video series I have embarked on a number of professional and personal projects which all use custom Firebase authentication. By this I mean a fully cusomised login / signup page and custom token minting to define user roles and authorisation. Leveraging the Firebase Functions makes handling custom requirements fairly simple. I plan to make videos on how to do all of this once I have some more spare time.

Agreed that this would be a massive step forward. I was thinking of making a video showing to push a list of all Firebase users into a Webflow CMS collection. However let me explain some limitations I have found with this:

  1. Webflow does not provide an api to dynamically change which cms items get displayed to your site’s visitor. This means that currently you can not (securely) display different Webflow CMS items to different users depending on who they are. Yes, you could do some JavaScript trickery to achieve this user experience on the client side, but of course this would be highly insecure.

  2. Webflow’s file uploads for images, pdfs etc have no security whatsoever. While the links themselves are fairly obfuscated, anyone can reach them without authentication. This means that you would still need to rely on your own databases (Firebase or whatever else you like) to store secure files for your users.

I hope that one day Webflow build out their apis and allow us to customise more. Until then I will keep trying to find ways around current limitations!



Hi Jason,

I had a look through your source code it looks great! Very similar to the things I have been doing that I mentioned in my reply to your latest question.

Maybe next have a look at building a Firebase Function that defines user roles, mints a new token, then add this as part of your sign up / log in flow?



I’ve been following along with your tutorial which is really well done, thanks for that. A question I have though, is it possible to use Firebase as a CMS and dynamically call posts into webflow? I think I’m on the right track getting it to work using - a css plugin for Firebase.

I found a guide that used node.js and express.js, but I do not believe that is an option with WF.


I’m sure this is entirely possible, I’ve never actually tried this myself. I’ll add this to my list of ideas for future videos, thanks!


This is really cool! I had not come across Flamelink yet.

Is it possible to use Firebase as a CMS?

Yes, seems so from reading their documentation.

and dynamically call posts into webflow?

If you mean from Firebase CMS directly to the client, without the Firebase CMS items never entering the Webflow CMS system, yes certainly. You just won’t be able to build out nice collection templates like you would if you used a CMS collection from within Webflow. This means you would need to deal with your own templating using either a library or code you write yourself.

You could of course use the Webflow CMS api to push data from your Firebase CMS to your Webflow CMS, but then you would have the same problem of not being able to securely and dynamically filter which CMS items get displayed to an individual site user.


Excellent tutorials! Your work may save my client’s project, if not within this season, then surely for next year. Right now, I am suffering from migraines trying to find a simple turnkey solution to member protection with paid subscriptions (Paypal/Stripe) AND multiple-access levels with one login (kind of like an eCommerce profile but with page protection). I’m not a developer/coder so my expertise is limited to HTML/CSS I have picked up along the way.

Currently we are using and for every subscription, a user has a new profile/login so this is frustrating for both the user and administration. Many users want to be able to purchase multiple subscriptions without having to sign-up all over again and we want to be able to protect certain pages that match the subscription.

Watched all of the videos (and subscribed :+1:t5:) and am wondering if keyfold will one day be able to soothe this need? If so, here are features I need for my clients:

  • Ability to protect/reveal certain pages individually per paid subscription (Ex: Subscription A gives access to Page 1, Subscription B gives access to page 2, Subscription C gives access to pages 1 and 2).
  • Ability for users to have one sign-on no matter how many subscriptions they pay for (Ex: If a user pays for Subscription A and B separately, they should still be able to access Pages 1 and 2 without having two profiles).
  • And of course, users who do not have a a certain paid subscription, can not view those pages where that particular authentication is found.

Great work and I can’t wait to see what you have in store for WF users!


Hey! I’m wondering if what you’re doing here is actually exactly what I’m looking for in the forum topic I just posted.

I’m building a website where I’m trying to let people sign up and post events and volunteer opportunities in their communities, as well as a few other types of things (links, discussion posts, although those are less important).

Basically, I’m trying to build a site that allows people to sign in and post things that then generate and populate new pages on my website. Would this allow me to do that?

I’m doing this website for my senior graphic design thesis project, and I saw that you’re releasing a plugin to add this login functionality really easily to webflow sites. The project is due in 3 weeks, so if you’re looking for anyone to beta test the plugin, I’d love to be able to use it on my site. If not, totally understandable.

Thanks for any help!!


Thanks so much for this feedback. Detailed use cases like what you have provided are a tremendous help to us in working out our roadmap. Your use case is pretty much exactly what I had assumed that people would want, so it’s great to hear you validate that.

Yea that sounds horrendous. I’m sure there is some reason that they do this, but this is certainly not how I envisage Keyfold working.

Definitely on our road map.

This is the most logical way of doing things, and definitely on our road map!

Yep definitely on our road map.

Once again, thanks for your detailed feedback. We are hoping to have some alpha testers trying Keyfold very soon so it should not be too long before a beta release.


Hey, thanks for the question. Is what you need a community forum like these Webflow forums? In that case, you don’t even need to build your own solution. Just use something like Discourse (which powers this website).

With this option, you could use Webflow to build a pretty landing page and meet your requirements as a graphic designer, then from there simply link to your instance of Discourse. This can handle all the user registrations, logins, password resets etc.

Otherwise long term yes, Keyfold will probably be able to solve your problem. Unfortunately it won’t be able to within 3 weeks :slight_smile:

Having said this, I do need to identify some alpha testers so if you’re keen just send me a message.


Publicly available CMS? Or am I looking for something different?