From Facebook Developer Wiki

We really want to help everyone use Facebook Connect. Facebook Connect is a set of JavaScript and REST APIs that any developer can implement directly into their site.

However, there may be many cases where you as a developer want to offer richer features that make it easier for others to integrate Facebook Connect into their websites. For example, building plugins for standard blogging software, or extensions for standard publishing systems. In these cases, you would want to offer your code as a plugin or "4th party" code running in another developer's website.

Does your favorite piece of software already have a Facebook Connect plugin? Check the Facebook Connect Plugin Directory. If not, then consider adding one on your own!

If you are thinking about building a plugin, here's a simple guide for the basic rules to develop a Facebook Connect plugin that you can offer to other developers to integrate into their websites. First, let's distinguish between plugins and widgets, the two types of 4th-party code that can be used with Facebook Connect.

[edit] What's a Plugin and What's a Social Widget?

Fourth-party code usually runs in one of two logical modes:

• As a plugin. In this case, the website owner downloads some code and installs it in their blog. Examples of good plugins are Movable Type and WordPress, found in the Facebook Connect Plugin Directory. To build one of these specifically, see How To Write A Good Connect Plugin.

• As a social widget. In this case, the website owner copies and pastes some client side code (JavaScript and HTML) from elsewhere. An example of a Facebook Connect social widget is the Fan Box.

Now that we've made that distinction, let's discuss the Golden Rule for 4th-party code: users connect with each website separately!

[edit] Enabling Users to Create Social Widgets and Plugins

If you are a 4th-party plugin or widget developer, you can enable users to create their own plugins and widgets using the Create Application API.

[edit] Users Connect with Each Website Separately

When a user connects with a website, they should establish a relationship with that site. If you are a 4th-party plugin or widget developer, then you should enable that direct relationship. A user does not establish a relationship with a 4th party widget.

The user should be able to recognize the site with which they are connecting. That means that all of these attributes should be consistent:

• The domain that the user sees in their browser
• The name and logo on the host site
• The name and logo that shows up in the Connect window

As an example, take a look at this screenshot from the TechCrunch Connect experience. See how it's clear and obvious that the user is connecting with this site, and this site only.

Now, suppose TechCrunch used a widget manufacturer to power their blog instead. Instead of logging in to TechCrunch, what if you instead connected with "Widgets R Us"? This would violate Platform Principles and Policies, and as a plugin author you need to make sure your users are not doing that.

The widget developer can have a relationship with the site owner, but not directly with the user. Any Connect buttons or functionality need to be done in the context of the website that hosts the widget. This means:

• Each site needs its own application key, with a Connect URL of the domain.
• Connect JavaScript code needs to execute in the context of the website domain.
• User data cannot be passed into iframes, unless it complies with the Developer Terms of Service and Platform Principles and Policies.

The user has established a relationship with two parties: Facebook and the website. A widget developer should not create a third connection.