Facebook Login has changed a lot in the past few months as we work to help protect people's privacy and give them greater control over their information. We realize it can be challenging to stay on top of all of the updates. To help you, we've compiled a summary of the recent changes, along with recommendations for incorporating them.
Keep in mind the following deadlines to help ensure smooth operation of your app or website.
In order to help protect people's data, we're now requiring that an increased number of permissions go through the App Review process. For certain permissions, we are also requiring business verification and a contract between your business and Facebook. Businesses can be verified by providing forms of documentation including utility bills, business licenses, certificates of formation, articles of incorporation, tax ID numbers, and others. The contract introduces additional security requirements and other provisions around data. You can read more about the enhanced App Review process in the App Review topic.
The table below summarizes the level of review necessary for Facebook Login permissions. Check back often for updates to this table.
|App Review NOT Required||App Review Required||App Review, Business Verification, and Contract Required|
* If you have not yet upgraded to Graph API, we recommend that you re-request these permissions by August 1. If approved for access, they will continue to be available to you after you upgrade to Graph API v3.0. Changes to Graph API v3.0 are detailed in this blog post from May 1, 2018. Apps have until Jan 8, 2019 to upgrade to Graph API v3.0.
If your app or website was already using the permissions shown in the table above before May 1, 2018 when our enhanced review began, you have until August 1, 2018 to re-request access and ensure you can continue to use them after then.
Businesses that build with the Facebook platform to serve other businesses as a third-party tech provider must also sign an additional contract. The tech provider contract restricts the usage of data to the sole purpose of servicing the customer on behalf of whom the data is collected. Large customers using third-party tech providers may be subject to App Review and may be required to sign the supplemental terms. Tech Providers must identify their business use as providing services to other businesses in the settings of the App Dashboard.
We have deprecated certain permissions and features, as shown in the table below. The fields previously accessible through these permissions will no longer be returned and APIs will return empty values.
|Extended Profile Permissions||User Actions Permissions||APIs|
All Mutual Friends
Read the blog post from April 4, 2018 for more information.
publish_actions permission was deprecated as of April 24, 2018. Apps created before this date that were previously approved to request
publish_actions can continue to do so until August 1, 2018. If you were using
publish_actions, we recommend switching to Facebook's Share dialogs for web, iOS and Android. (Read the blog post from May 1, 2018.)
The following permissions are no longer available to request as of May 1, 2018 and will be deprecated starting January 8, 2019 for apps and websites that gained approval prior to May 1, 2018:
See the blog post from May 1, 2018.
You can see the full list of permissions at Permissions Reference.
Links to user profiles built using ASIDs no longer function. You must retrieve a profile link from the
user_link field. These links will not function if the person hasn't used your app or website in 90 days, or if the person has declined to grant the
user_link permission to your app. After migrating to Graph API v3.0, this field will only be available if your app requests and the user approves the permission.
user_link will only resolve to the user's actual Facebook profile for logged-in individuals in that person's extended network (currently defined as friends-of-friends but subject to change). Other individuals may only have the opportunity to send a friend or message request.
Read the blog post from April 19, 2018 announcing these changes.
Your application's access to user data now expires after 90 days unless Facebook is able to verify activity in your app. On some platforms, like Facebook web games, all user activity may be verifiable, and on other platforms, like iOS, users may have to re-authorize your application's data access by accepting permissions in a Login dialog every 90 days. Read the blog post from April 9, 2018.
We recommended that you make sure your apps/websites have a smooth re-authorization flow for people whose access tokens have expired. Read more about refreshing access tokens at Refreshing User Access Tokens
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.
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.
These updates were announced in a blog post on May 1, 2018.
“Business Integrations” appears 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, ads, or page messaging. 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. Read the blog post from May 1, 2018 announcing this change.
If people remove your app or website from Facebook's apps and websites settings, we can provide them with the option to request that your app or website delete all information you received about them from Facebook. The experience on Facebook will inform people when they sent a request and when it was acknowledged by your service. It will also provide them with a confirmation number you supply and a way to check the status of their request. Offering this option to people can help you automate customer service requests, demonstrate that you're handling their information responsibly, and help meet your compliance requirements, such as for the GDPR.
To enable this option, we need you to provide us with a callback URL where we can send the request. You can add the callback URL at your app's Facebook Login Settings page in the app dashboard. Your callback must use HTTPS. See the documentation for details. Read the blog post from May 25, 2018.
We are now offering a way for you to easily provide your DPO's contact information to European users. Go to your app's Facebook Login Settings page in the app dashboard to add your DPO's name (optional), mailing address, and email address. This information will be made available in people's apps and website settings so that they can contact your DPO if they have questions about how their data is processed and used. Read the blog post from May 25, 2018.
For apps in development mode, API calls will return user data only for those with a role in the app (i.e., admin, developer, or tester). This applies to the Facebook Profile, Pages, and other APIs. Read the blog post from April 24, 2018.
Apps in development mode are now rate-limited to 200 calls per hour, per page-app pair, and can only access users who have a role on the app (admin, developer, or tester). View the charts for your app's rate limit activity on your app dashboard. Developers and Admins of apps in public mode can only access the permissions the app was approved for.
We recommend that developers take these limitations into account when developing new features for their apps.