You may want to build your apps with both a custom login mechanism and Facebook Login. This guide covers some of these scenarios and gives you tips for handling a person's experience using these apps.
You can implement your own login system where someone signs up for the app using their email and password and an account is created for them. Typically, apps use an email verification step in this case to authenticate identity.
Alternatively you can choose to use Facebook Login completely for their login system. In this case a person signs up for the app using Facebook Login, an account is created for them, and the authentication step is taken care of by Facebook.
Beyond these scenarios, your app may need to handle more complex situations:
This guides outlines what we think are the best ways to handle these situations.
This section covers the case where someone uses an app's custom login system to create an account. Later, while they are still logged in they want to associate their Facebook account with it. For example, people can sign up to Spotify with an email address and a password, but they can later choose to associate that account with their Facebook account using Facebook Login, such as when they want to publish their listening activity to their timeline.
Read our guides to using a Facebook Login flow in your app to complete this step. In the Spotify example, you begin Facebook Login flow to the point in the app where the person indicates that they'd like to publish their listening activity, or you might offer an explicit option to link their account with their Facebook account.
Once a person logged in to your app using your own login system, and then completes the Facebook Login flow, your app will have two very important things that must now be merged:
In the majority of apps, the original account will have been stored in a database table, so the simplest approach is to associate the Facebook account information with that account in the database.
It is generally better to create a new table in which you store the person's Facebook account information. The advantage to keeping a separate table in lieu of adding more columns to your existing account table is that it enables you to quickly support other OAuth account logins over time.
In the future, if the same person chooses to log in to your app, you can match the information stored in the database to log them in using either method seamlessly.
In this situation, a person logged in to your app with their own credentials such as an email and password for example. Later, when the person logs out they choose to sign in to your app using Facebook Login. Your app will now have two accounts for the same person, one created via the app login system, the other created via the Facebook Login flow. In order to provide the best experience for that person, your app should attempt to merge these accounts into one.
This guide assumes that each account created by your app has an email address associated with it. However, it is possible that the person has used a different email to create their existing account than the one they have associated with their Facebook account. In this case, you should offer people an explicit 'Account Merging' option somewhere in your app and then allow the person to manually specify the two separate accounts that they wish to merge.
Additionally, if your own custom accounts do not store an email address, then again, you will need to allow the person to manually specify the accounts that they wish to merge.
If your app's own custom login system uses an email address to uniquely identify each account, you should also ask for the person's email address (using the
After a successful login using Facebook, you will have the person's email address, Facebook ID, and access token. Your app should search for an existing account that has been created with that same email address. If one exists, you should merge the two accounts and add the Facebook info to the existing account - as recommended above.
At this point, you should log in the person as you normally would.
If there is not an existing entry in your database with that email address, then you should consider them to be a new user.
This situation occurs when someone creates their account in your app using Facebook Login, but later wants to also log in to the account using a unique credential and a password. For example, Netflix has a web app that uses Facebook Login alongside a regular login system, and also an Xbox 360 app where people can only use the regular login system.
If you use an email address as the unique credential which identifies each account, your app should verify that the email address associated with the person's Facebook account (and obtained during Facebook Login) is valid. You can do this by creating code in your app to send a verification email to the address obtained after Facebook Login (you will probably need to have this step as part of your regular login system anyway).
Once the email address is verified, you can now request that the person supplies a password, indicating to them that they can use this to log in to your app in future in conjunction with their email address. Once supplied, you can add this to the same part of your database where you are currently storing account information.
If your app's login system doesn't use an email address as the identification and uses something user-generated like a username instead, then you should also request that the person supplies this at the same time as a password.
People might also expect that your app offer the ability to remove Facebook account association from their login account - this should simply involved stripping your account database table of the Facebook info for that particular person.