Connect/Authentication and Authorization
From Facebook Developer Wiki
You can use Facebook Connect functionality as a login mechanism for the users of your website, iPhone application, or desktop application. Your users can connect their accounts on your site or application (if one exists) with their Facebook accounts. Using Facebook Connect, your users can link accounts, then you can start making a richer, more social experience on your site with your connected users' Facebook data. What's more, you can have users share their activities on your site back on Facebook.
Contents |
Benefits
Using Facebook Connect to authenticate your users has many significant benefits.
- Our research has shown that sites that implement Facebook Connect see user registration rates increase by 30 - 200%.
- With just two clicks you can offer a user-customized experience on your site – the user connects to your site, then you can immediately display that user's data on your site, personalizing his or her experience quickly and easily.
- When a user has authorized your application, you can make API calls to Facebook to get more user data so you can provide a more personalized experience.
- You can prompt a user for extended permissions for an even deeper integration with Facebook.
How It Works
When a user visits your site or installs your application, you can display a Facebook Connect button, like the following:
If you have an iPhone app, you can display a button like this:
When the user clicks the Connect with Facebook button, a Facebook Connect dialog appears. What the dialog displays depends upon the user's Facebook state:
- The user is logged into Facebook.
- The user is not logged in to Facebook.
- The user is not registered with Facebook.
Scenario 1: User Is Logged in to Facebook
The user visits your site and sees the Connect with Facebook button. The user clicks the button to log in to your site.
If the user is logged in to Facebook, Facebook detects the user's login state and displays a Facebook Connect dialog that easily allows the user to connect to your site:
The user clicks the Connect button and is immediately logged in to your site. Notice that your site is aware of the user's Facebook presence, and displays the user's Facebook profile pic and name as well as some of the user's friends who have already connected to your site.
Scenario 2: User Is Not Logged in to Facebook
The user visits your site and sees the Connect with Facebook button. The user clicks the button to log in to your site.
If the user is not logged in to Facebook, Facebook displays a Facebook Connect dialog. This dialog prompts the user to enter his or her Facebook login credentials:
The user enters the login credentials, clicks the Connect button, and is immediately logged in to your site. Notice that your site is aware of the user's Facebook presence, and displays the user's Facebook profile pic and name as well as some of the user's friends who have already connected to your site.
Scenario 3: The User Is not Registered with Facebook
The user visits your site and sees the Connect with Facebook button. The user clicks the button to log in to your site.
If the user is not registered with Facebook, Facebook displays a Sign Up for Facebook dialog. This dialog prompts the user to register for the Facebook:
The user signs up for Facebook but may log in via Connect only after their email address has been validated. Notice that your site is aware of the user's Facebook presence, and displays the user's Facebook name.
Scenario 4: Prompting the User for Extended Permissions
Some sites ask the user to grant them special extended permissions when the user first connects, as it's a necessary part of their Connect integration. For example, a site might immediately need to read user data after the user connects because the user's stream is part of the site or application's experience.
Facebook recommends against prompting for permissions right after the user connects, unless you must use what the permission grants immediately.
In this case, the user clicks the Connect with Facebook button on the site, and the Connect with Facebook dialog appears.
After the user clicks Connect, the permissions dialogs appear. In this case, the site is asking for constant authorization/offline access and the ability to read from the user's stream (Feed and Wall).
The user can choose to grant both permissions, just one of them, or none of them.
After the user finishes granting permissions, the user returns to the site, with the user's Facebook information prominently displayed.
Implementation
Implementing authorization follows pretty similar paths for websites, desktop applications, and iPhone apps.
- Authorization and Authentication for Facebook Connect Websites
- Authorization and Authentication for Facebook Connect for iPhone
- Authentication and Authorization for Facebook for Mobile Applications
- Authorization and Authentication for Desktop Applications
Implementation Notes
The user's browser must be set to accept 3rd Party Cookies in order for it to stay connected between clicks.
Facebook Connect Tutorials
Here's a tutorial that shows how to integrate Facebook Connect into an existing PHP site.
Best Practices
You should consider the following best practices as you design your authorization and authentication model.
Access More User Data
When your users connect their accounts on your site with their Facebook accounts, you'll have the ability to access more information than you'd ever get on a registration form. And by prompting users for extended permissions, you can get even more data.
No Need to Create Separate Accounts
In general, it's not a good practice to force a new user to create a separate account when registering on your site with Facebook Connect. You'll have the user's Facebook account information, and can create a unique identifier on your system for that user.
Just make sure you understand what Facebook user data you can store, or simply cache for 24 hours. See Storable Data for details.
If the user ever deactivates his or her Facebook account, you have a chance to contact the user to request the user create a new account on your site. When a user deactivates his or her account, we ping your account reclamation URL to notify you of the deactivation. Then Facebook sends the user an email regarding the deactivation. If the user has connected accounts with any Facebook Connect sites, and if your site has specified an account reclamation URL, the email will contain a section with your application logo, name, and reclamation link, in addition to an explanation about the link's purpose. For more information, see Reclaiming Accounts.
Don't Always Display the Login Button
It's ideal if you display the login button only if the user is not connected with your site. If the user is already connected, clicking the login button will not prompt any user interface, although any registered callbacks will be called.
If this is a first-time user (that is, they're connecting with your site for the first time), we will also ping the Post-Authorize URL specified in your application's settings, if such an URL exists.
Link Existing Accounts
If the user already has an account on your site, it's a good idea to link accounts. To do this, see Linking Accounts and Finding Friends.
Check for Permissions Before Prompting
Since you know the UID of the viewer, you can check for permissions he or she may have granted your application, so check to see if the user granted your application publish_stream, for example, so you know whether you can publish to the user's profile. To check if the user has a given permission, call the users.hasAppPermission method on the Facebook RESTful server.
For Facebook Connect websites, while you can prompt the user for the offline_access permission, it's not a recommended approach, as the user might not expect actions to be taken by your site on the user's behalf when the user isn't actively using your site.
Prompt for Permissions at the Appropriate Time, not at Login
Even though it might seem more logical to prompt a user for extended permissions as soon as the user connects accounts, you should consider delaying the prompting for a permission until it makes sense in your application flow.
For example, don't prompt the user for the publish_stream permission when the user connects; wait until the user goes to share something on Facebook from your site. Or don't prompt for the email extended permission until the user signs up for alerts on your site.
Gain Access to Reliable Communication Channels
You can prompt your users for the email extended permission. This is a real email address, not some spam account. This will also automatically change if the user updates it on Facebook. This won't require a confirmation.
