User accounts

In this article, we'll look at how Bubble handles setting up and managing user accounts.

Technically, users are just another data type in your app's database. But user accounts carry a lot of responsibility, so Bubble treats the User data type a bit differently from the rest:

Account security is hard to get right, and it works much the same way across most apps. That's why Bubble takes care of the underlying mechanics: it saves you development time and keeps the security side of user accounts up to date without extra work on your part.

Most of us have dozens or even hundreds of user accounts: we're logged in to our phones, our email, social media, forums, and even newspapers. We all know what they are, so let's change perspective a bit: why does an app need user accounts?

The first answer is that not every app does. You can build a highly useful app where nobody ever creates an account, even one that lets visitors add and change things in the database. So it's worth separating two ideas: your app can have users, registered users, or both. Every visitor is a user, but only those who sign up become registered users. This article focuses on registered users, meaning users who have signed up with an email and password or through a third-party service.

Registering users serves many purposes:

As you can see, user accounts aren't only about security and privacy. Just like any other data type, you can add as many fields to the User data type as you need. The User type also comes with a few fields of its own to handle the account. These can't be changed or deleted, and they're the same in every Bubble app.

Like other data types, the User type has a set of built-in fields. On top of those, it comes with three fields of its own:

The email field can't be empty on a registered user, and it needs to be a valid email address. Every user in your app needs a unique email address, so two users can't sign up with the same one.

The password field is different from every other field: it's invisible, even to you as the app developer. Bubble stores passwords following industry-standard practices.

The Email confirmed field is also invisible. It holds a yes/no value that shows whether the user has confirmed their email address. The value changes to yes when the user clicks the link in a confirmation email, sent either by the Send confirmation email action or by the Sign the user up action with Send an email to confirm the email checked.

You can't change this field directly. Only the user can update it, by confirming their email.

This article covers the most common actions for user accounts, but not every one. To see all the actions and operators available for users, check out the references below:

Reference: Account actions
Reference: User operators

Bubble handles the technical side of signing users up, but the design and user experience are entirely up to you.

To sign a user up, you need two pieces of text from them: a valid email address that isn't already in use in your app, and a password. You collect these with input elements and pass them to the Sign the user up action.

The Sign the user up action has these main properties:

Add an input for the email address and one for the password. If you want users to confirm their password, add a second password input.

Set the email input's content format to Email and the password inputs' content format to Password, so the email is validated and the password characters are hidden.

Add a button, such as Sign up, and start a workflow with the An element is clicked event.

Add the Sign the user up action. Set Email to the email input's value and Password to the password input's value. If you added a second password input, check Require a password confirmation and set Password confirmation to that input's value.

If you collect more information at signup, like the user's name, check Change another field and map each field to its input.

Add a Go to page action to take the new user where you want them, such as a dashboard or a welcome page.

The email and password are sent to Bubble's server encrypted, and the password is hashed and salted, so no one can read it, not even the Bubble team.

As soon as the action runs, Bubble creates the account and the user is logged in. The session lasts for 365 days, or until the user logs out or clears the cookies in their browser.

Logging a user in works much like signing them up. The Log the user in action needs two inputs: the email and the password. Bubble sends them to the server encrypted to check the credentials, and if both are correct, the user is logged in.

The Stay logged in property controls how long the session lasts:

A common setup is to add a Remember me checkbox to your login form and use its value for the Stay logged in property, so each user can choose.

Instead of an email and password, you can let users sign up and log in with an account they already have, such as Google, Facebook, LinkedIn, or X (Twitter). This is often called social login, and it works through a standard called OAuth.

Third-party login has a couple of advantages:

Bubble offers plugins for several services, and you can find more in the plugin marketplace. You can also connect to other providers with the API Connector.

Let's say your app has a button labeled Log in with Facebook.

When you set up this flow, you define the level of authorization your app needs. By default, most services only share the user's public profile and email address, but you can ask for more permissions if your app needs them.

Only ask for the permissions your app actually uses. It's better for your users' privacy and security, and a long list of permission requests can lead to fewer users signing up.

When a user signs up with Facebook, Bubble creates a new user in the database, just like a regular signup with an email and password. The difference is how they log in later. Since they never set a password, they log in with Facebook again. If they're already logged in to Facebook in the same browser, that's usually a single click.

A user can have both a traditional login and one or more social logins. This can play out in a few different ways, which we cover in the article series below:

Article series: OAuth plugins

Signing a user up gives them an email address and a permanent place in your database. In many cases, it's also when they choose a password.

But Bubble starts keeping track of who the user is before that. When someone visits your app for the first time, Bubble saves a cookie in their browser and creates a temporary user. That lets you remember who the user is during their visit and build logic that relies on data stored on the current user, such as:

A temporary user stays active on the same device for 72 hours. When the user signs up, Bubble automatically transfers the data stored on the temporary user to their new account.

There's one exception: in the Settings tab, you can stop Bubble from setting cookies on new visitors automatically. If you do, Bubble doesn't create a temporary user until the visitor accepts cookies through the Opt-in to cookies action. Until then, anything stored on the current user is lost when they close the browser tab.

Bubble for native mobile apps uses the same user accounts as your web app within the same project. A user who signs up on the web can log in to your iOS or Android app with the same credentials, and the other way around.

Beyond signing up and logging in, Bubble includes actions for most of the account tasks your app is likely to need:

Reference: Account actions