From Facebook Developer Wiki

With the new profile design, we've changed the way users interact with your applications. We're providing as frictionless an experience as possible for users. This way a user can engage with your application quickly and easily, and decide how to integrate it into the profile as the user continues to engage with it.

On the new Facebook profile, a user can begin interacting with your application immediately. You don't need to have a user authorize your application as soon as the user visits your canvas page. A user authorizes an application when the application presents a login screen where the user accepts the application's terms of service and lets the application access his or her profile data.

Note: Much of this information is discussed at New Design User Login.

Note: If you're creating a desktop application, the login procedure is different. Please read Login Desktop App.

[edit] What You Get Before a User Authorizes Your Application

Facebook now publishes metrics based on monthly active users. A user doesn't have to authorize your application before being considered an active user. And if the user interacts with your application profile box (and soon, tab or Publisher) on a friend's profile, that user is counted as an active user.

When a user who hasn't authorized your application visits your application's canvas page, Facebook sends you some user data and lets your application take a number of actions. The following occurs:

• Facebook passes the viewing user's ID to your application.
• Facebook passes the viewing user's friend UIDs.
• You can call any API method that doesn't require a session.
• You can get user information that's publicly available via search (except for any users who have chosen to not display a public search listing).
• You can use FBML tags to show a user's profile pic and name based on the UIDs passed.
• You can publish Feed stories by the user via Feed forms.
• You can send requests on behalf of the user via request forms.

[edit] What You Get After a User Authorizes Your Application

Once a user authorizes your application, the following occurs:

• Whenever the user interacts with your application, Facebook passes a temporary session key, giving your application access to more user data which you can query on behalf of this user.
• You can call users.getStandardInfo to get data for analytics, even without an active session.
• You can send this user notifications on behalf of your application.
• With an active session, you can send notifications on behalf of this user to the user's friends or to other application users who are not friends of the user.
• You can prompt the user to add integration points (such as a profile box or application info section) to his or her profile. The user can also add a tab for your application to his or her profile.
• Users can interact with your application's Publisher integration.
• You can prompt the user to grant your application extended permissions, so your application can send the user email, update the user's status, and so forth.
• You can publish one line Feed stories through the API to this user.

[edit] How Users Can Authorize an Application

A user can authorize your application in a number of ways:

• If your application uses the Facebook PHP client library, you can call require_login, which redirects a user to login.php. You can call require_login like this:
  
  <?php require_once 'facebook.php'; $appapikey = 'YOUR API KEY'; $appsecret = 'YOUR APPLICATION SECRET'; $facebook = new Facebook($appapikey, $appsecret); $user = $facebook->require_login();

• If your application does not use the Facebook PHP client, you can redirect users to login.php. For example, you can use the following FBML code. The canvas GET parameter redirects the user to your canvas page after login; otherwise, the user gets redirected to your callback URL.
  
  <fb:if-is-app-user> <!-- your normal code --> <fb:else> <fb:redirect url="http://www.facebook.com/login.php?v=1.0&api_key=[your_app_key]&next=[your_canvas_page_URL]&canvas="/> </fb:else> </fb:if-is-app-user>

• You can include the requirelogin attribute in links and on forms. This pops up a lightweight Ajax dialog. Don't use this attribute if you need to redirect the user after authorization (see below).

The user needs to authorize your application only once.

Note: Facebook has deprecated require_add. However, if your application still calls the method, the behavior will be similar to require_login, as all requests to add.php will get redirected to login.php.

[edit] URLs Relevant to Authorization

Once a user has authorized your application, you can utilize the following URLs, which you specify in your application's settings in the Developer application:

• Post-Authorize Callback URL: Facebook pings this URL when a user authorizes your application for the first time. You can also call users.isAppUser to determine if the user has authorized your application.
• Post-Authorize Redirect URL: You can redirect a user to this URL after the user authorizes your application for the first time. You can use this URL only if the user authorizes your application through login.php and not the login dialog.
• Post-Remove Callback URL: Facebook pings the URL when a user removes your application.

[edit] Parameters Passed to Your Application

Facebook sends parameters to your application in the form of a signature (read more about signatures below). Which parameters are sent depends upon what the user is doing with your application.

For FBML canvas page applications, the parameters are sent as POST parameter. For iframe applications, the parameters are sent as GET parameters, unless you are preloading FQL using the fb_iframe_post option, in which case the parameters are sent as POST parameters.

Facebook passes the following parameters to your application when a user interacts with your application:

• fb_sig_added: If set to true, then the user has authorized your application.
• fb_sig_api_key: Your application's API key.
• fb_sig_friends: The UIDs of the visiting user's friends.
• fb_sig_locale: The user's locale.
• fb_sig_time: The current time, which is a UNIX timestamp.
• fb_sig_user/fb_sig_canvas_user: The visiting user's ID. fb_sig_canvas_user is passed if user has not authorized your application, while fb_sig_user is passed if the user has authorized your application. Neither is passed when an application tab is being requested; fb_sig_profile_user is passed instead.
• fb_sig_linked_account_ids[n]: These are the account_id values that match the user's email hash that were previously sent to facebook using connect.registerUsers

Note: As described in Automatic Authentication, the fb_sig_canvas_user and fb_sig_friends parameters are only passed when a user arrives at your application from a link within facebook.com and provided the user's privacy settings allow the user to be seen.

Note: As mentioned in Bug 4117, there are some situations in which both fb_sig_user and fb_sig_canvas_user are passed when the user has not authorized the application (i.e. fb_sig_added is 0).

Facebook passes the following parameters only if fb_sig_added is true (that is, if the user has authorized your application):

• fb_sig_session_key: The valid session key for this user. This parameter isn't passed when an application tab is being requested; fb_sig_profile_session_key is passed instead.
• fb_sig_expires: The time when this session key will expire. This parameter is set to 0 if the session is infinite -- that is, the user granted your application offline access. This is a UNIX timestamp.
• fb_sig_profile_update_time: The time when this user's profile was last updated. This is a UNIX timestamp.
• fb_sig_ext_perms: Any extended permissions that the user has granted to your application. This parameter is sent only if the user has granted any.

These parameters are relevant to requests sent to your application:

• fb_sig_in_canvas: This parameter is true if the request is for your application's canvas page.
• fb_sig_in_profile_tab: This parameter is sent if this request is for a user's tab for your application.
• fb_sig_profile_user: The user ID of the profile owner for the tab being requested.
• fb_sig_profile_session_key: The session key for the profile owner, which you use to render this user's profile tab content.
• fb_sig_page_id: The ID of the Page if this request is on behalf of a Page.
• fb_sig_page_added: If this request is on behalf of a Page, this parameter indicates whether the Page has added this application.
• fb_sig_logged_out_facebook: This parameter is sent if the user is not currently logged into Facebook.
• fb_sig_ss: The session secret, used in place of your application's secret key for secure API calls. This is sent only to a SWF rendered by fb:swf that resides within the domain or subdomain of your application's callback URL. The session secret also gets passed to a SWF object inside your Publisher, and can be passed to IFrames rendered with fb:iframe.

[edit] How Signatures Are Generated

You can read about how these signatures are generated. This applies both to the signatures Facebook generates and the ones that your application needs to generate, only the parameters that get passed may be different.

[edit] About Session Keys

Applications no longer receive infinite sessions when a user authorizes your application on the new profile. Instead, Facebook sends your application a temporary session key that lasts an hour or until the user logs out of Facebook.

Each time a user who has authorized your application interacts with it, Facebook will renew the temporary session and send you the session key, even when this user visits a page in your application that doesn't require authorization. You don't need to make any calls to get this key.

While the user is on your canvas page, Facebook continues to renew the session key by pinging its servers.

If your application doesn't have an active session key and it needs one, you should direct the user to login.php (like you would with require_login); if the user has authorized the application previously, a session will be established automatically; otherwise, the user sees the authorization prompt.

We deprecated infinite sessions granted on the old profile. However, if a user explicitly granted your application an infinite session by logging into your application on the old profile and checking the Keep me logged in check box, you'll continue to have an infinite session/offline access for that user.

If necessary, you can prompt your users for an extended permission to grant offline access to your application. When a user grants your application offline access, we'll return a session key with that user's user ID appended to it (the fb_sig_session_key parameter).

Many API calls no longer require session keys. To determine which ones do and which ones don't, we've grouped API calls into three categories:

• Methods that always require a session key
• Methods that never require a session key
• Methods that don't require a session key, but offer additional functionality if one is passed