Facebook Login makes updates to further protect privacy

In our continuing work to strengthen people's trust with Facebook and provide developers with tools to create an even better user experience, we are making the following updates to Facebook Login:

• Restricting Data: simplifying public profile, deprecating profile fields, and limiting user profile links to protect people’s privacy
• Handling Token Expiration: offering you new tools to handle a user's token expiration and refresh gracefully
• Introducing Personal Data Deletion Callback: providing a callback URL to receive a person’s request that the info an app received from Facebook be deleted
• Clarifying Business Integrations: showing these services as a distinct list separate from apps

Restricting Data

As part of the commitment we previously shared, we've simplified public_profile to include only name, picture, and an app-scoped ID (ASID) in the new Graph API v3.0. App review will be required to request access to a user's gender and age_range. The following fields on GET /{user-id} have been deprecated: timezone, locale, cover, is_verified, updated_time, verified, currency, devices, and third_party_id. These changes apply to newly-created apps as of today, and to all apps regardless of API version starting on January 8, 2019.

We are also altering how profile links work. These links are intended to allow people who have social interactions in your app to find and connect with each other on Facebook. To make it more difficult to use this feature in other, unintended ways, we are making the following changes:

• Links to user profiles built using the previously supported patterns with an ASID will cease functioning immediately. If you have old links for your users that you've stored, you will need to refresh them from the graph.
• Apps that want to show a user profile link will need to retrieve that data from the link field on user object, and beginning with Graph API 3.0 the ability to request that field requires your app be approved for and the person to grant you the new user_link permission. These links should be treated as opaque. They will stop functioning if the person removes that permission from your app or when access to a user's personal data expires. These links should not be shared except with other users of your app. They may not be used by developers, employees, or other agents to gather data about individuals on behalf of your app and should not be shared with third-party analytics services, customer data platforms, or similar.
• For most apps, links will only redirect to the individual's Facebook profile for logged in people in the person's extended network. Soon, other logged in people will be able to invite the person referred to by the link to connect with them on the Facebook platform.

Handling Token Expiration

We're clarifying the difference between visitors who never logged in and users with expired access tokens so that developers can show the most appropriate user interface for each situation. For apps using the JavaScript SDK, FB.getLoginStatus() allows you to determine the state a user is in, and now returns a new status, authorization_expired, to indicate that a user's token has expired. This new state is distinct from the not_authorized state that you'll get for users who have not formed a connection to your app via Facebook Login. For this new expired state, you might remind the individual they've previously logged in with Facebook and prompt them to go through the login flow again to refresh their account with their latest info.

We're also providing a new way for developers to test token expiration in their apps and websites. For each test user created for your app, you'll be able to choose the length of time before the access tokens expire. If you choose to use a custom expiration time, you can set the interval for as short as one minute or much longer if needed for your unique app testing purposes. You can find this setting under the Edit menu for each test user, and it applies to all of the apps or websites used by the test user.

For the JavaScript SDK, we're adding a new field to the authResponse object called reauthorize_required_in. This gives developers working with short lived tokens the ability to know when a person's 90 day authorization of the app will expire. If you want to proactively extend the person's session by another 90 days, you can call login() with the auth_type=reauthorize parameter, which will ask them to accept the permissions currently granted to your app again in order to continue.

Introducing Personal Data Deletion Callback

To help developers and businesses better comply with people's privacy wishes, apps will soon be able to specify a callback URL to receive a person's request to delete data the app received from Facebook. People will be able to request that the website/app delete their account and all associated information received from Facebook when they remove an app from the apps and websites settings (or at any later time). Developers receiving this callback from Facebook must provide the individual with a way to track and check the status of their request. We will announce the release of this feature, along with instructions for implementing the callback function, later this month.

Clarifying Business Integrations

Starting today, “Business Integrations” will appear as a distinct list of services separate from apps under a person's account settings. These are services that people connected to their Facebook account and granted special permissions to manage pages, events, groups, ads, or messaging through Messenger or Instagram. Your access to business APIs will continue to work as it did prior to this change, without expiration, until such time as a Facebook user removes the integration to the page, ad account, event, etc.

Thank you for your partnership as we work to increase trust and value across the ecosystem.