The most common way to authenticate users is to prompt them to enter a password or an email. However, very often, you will be using some external services to authenticate users using their credentials from another service. This is done through plugins. Doing so has a few advantages when you design your app. We'll use Facebook as an example below (in other words, your app offers a button 'Login with Facebook'.).
This lets your users authenticate faster into your app, and they don't need to remember another password. Usually, most services offer a straightforward, one-click authorization flow to authorize an app to use their identity with them. For instance, you will need one button 'Login with Facebook', and the user will be prompted by Facebook to authorize your app to use their credentials.
This also lets you make some calls to the service on behalf of the user. With Facebook, this lets you fetch their email (registered with Facebook), get their profile pictures, post on their wall, etc.
When you set up such a flow in Bubble, you will need to define the level of authorization you want from your users for your app to function. By default, most services only expose the public profile and the email when users sign up on a third party application using their credentials, but you can ask for more permissions (for instance, post on their wall).
Note that you should only use social logins and ask for permissions if you need them. Asking for permissions to access some data is something that users are sensitive to, and can lead to fewer sign ups.
When a user signs up with a social network (Facebook) in Bubble, a new user is created in the database, similarly to a traditional sign up flow with email and password. The main difference is that the way to login for the user, once logged out, will not be by entering their password (since their didn't define one), but by logging in with Facebook. If a user is logged in with Facebook in a browser, and if your app uses Facebook login, the user is automatically logged in as the current Facebook user.
Users in Bubble can use traditional logins and social logins at the same time. There are a few cases here.
If the user is currently logged in with email and password, you can prompt them to link their account with an Oauth provider (such as Facebook, Google ...). If a user goes through such a flow, a new user will not be created, but, instead, the Oauth credentials will be added to the current, logged-in user. After this flow completes, the user will be able to login either with his email/password, or via an Oauth flow. If another user exists in the database with the email provided by the external service, the action will fail and a message will be shown to the user.
If the user isn't logged in when he goes through an Oauth flow, a new user will be created, except if a user with the same email (the email registered with Facebook) already exists in the app's database. In such a case, the workflow will fail and a message will be shown to the user.
If a user has signed up with an external service and wishes to add a password to his account, he can do this by going through a 'reset the user's password' action. This will effectively modify the user that was authenticating only with Oauth credentials and will the email and password values to the user object.
Commonly asked questions relating to Oauth
Q: How do I attach a new Oauth service to a user that already exists in my Bubble app?
When a user is already signed in, using the "Signup/Login with a social network" with an Oauth service will "link" that user's account on that service to their Bubble app user record.
Q: Do I need to handle refresh tokens by myself?
Generally, no, if you're just using a plugin to provide Oauth login and if the plugin you're using was designed with this capability (and most generally are).
One case where you may need to handle refresh tokens is if you're building your own plugin or API connection to enable Oauth. For example, your app may have users authenticate into Google so that you can do things on their behalf with their Google data (e.g. check their email every X hours regardless of whether the user is active on your app). In these cases the plugins that provide Google Oauth will not be enough for your use case; you might want to build your own (or find a different plugin). If you're building your own plugin or API connection, here's some documentation suggesting how you'd handle the refresh token for Google in particular.
Q: My users who signed up via Oauth keep getting logged out automatically - help!
Oauth logins sometimes do have a natural timeout to help improve end-user security, but this is usually on the order of magnitude of days or longer. If you're seeing that your users can't stay logged in for shorter periods of time, there may be something amiss with the refresh tokens (the way that Oauth permission grants get automatically renewed over time).
These are tricky problems to debug because they often involve something going wrong with the plugin (or API connection) you're using or with your configuration with the third party itself. One thing to try is to install a different plugin offering Oauth with the same service, signing a test user up via that new plugin, and seeing if the same problem occurs for that user. If that doesn't help, the Forum may reveal other users who have solved the issue for that specific Oauth provider.
Q: Can I switch which plugin I'm using for a certain Oauth service and still maintain all my users' ability to log in with that service?
Different plugins for the same Oauth service are effectively treated like different Oauth services by Bubble. For example, if Plugin 1 and Plugin 2 both let you signup / login with Google, switching from 1 to 2 will NOT automatically preserve all your users' ability to log in with Google.
To handle this migration: let's assume you want to move from Plugin 1 to 2. Keep both plugins installed in your app for a little while. When users are logged in (e.g. via Plugin 1), prompt them to kick off a workflow that has the "Signup/Login with a social network" action with plugin 2 - this will associate 2's Oauth service with the user. After all or most of your users have done this, it's then safe to remove plugin 1. (Any stragglers could always add a password to their account via the reset password flow.)