Facebook's Graph API 2.0 Upgrade and ACS

Updated: July 17, 2015

On April 30, 2015, all Facebook-enabled applications will be automatically upgraded to Facebook’s Graph API v2.0. If you use Facebook as an identity provider in an ACS namespace, you may need to make changes to your Facebook identity provider configurations in ACS, code changes to your application, or both to avoid downtime.For more information about Facebook’s plans, see the Facebook Platform Upgrade Guide.

Background

ACS uses the following Facebook endpoints: https://www.facebook.com/dialog/oauth, https://graph.facebook.com/oauth/access\_token, https://www.facebook.com/logout.php and https://graph.facebook.com/me. Facebook will automatically upgrade these “version-less” Graph API requests to use v2.0 on April 30, 2015.

When adding Facebook as an identity provider in ACS, ‘email’ is set as an application permission (by default). If you have chosen no application permissions (empty field) or the default (‘email’) in your Facebook identity provider configurations, then you do not need to make any application or configuration changes. If you have chosen other application permissions, then you should review this topic completely to assess impact and take appropriate steps.

Assessing Impact

The following changes made by Facebook need your consideration:

• Permissions

  • The ‘basic_info’ permission, which is implicitly part of every Facebook request, will be replaced by the ‘public_profile’ permission, which will also be implicit. The permission sets for the two are identical, except that in the latter case the list of friends will be part of a separate permission ‘user_friends’. To get equivalent functionality to the ‘basic_info’ permission, you will need to request the ‘user_friends’ permission explicitly.

  • Significant changes have been made to ‘friends’-based permissions. The Facebook Platform Upgrade Guide outlines them in detail.

  • Facebook requires applications that request additional permissions beyond ‘basic_profile’, ‘email’ and ‘user_friends’ to go through their Login Review  process.

• Declined Permissions

  • Facebook will allow users to choose which permissions to grant to an application, with the option to selectively decline permissions. Applications will have to handle these use cases.

  • Users cannot decline the ‘public_profile’ permission.

  • If the user declines the ‘email’ permission, ACS will not pass the ‘email’ claim in the token back to the application.

• App-scoped User IDs

  • User IDs sent in the ACS token as the ‘Name identifier’ claim will go from being globally-scoped IDs (same User ID across multiple Facebook applications) to app-scoped IDs (different User IDs for each Facebook application).

  • This is the case only for Facebook users newly signing into the application. It is backward-compatible for users who have already signed in to the application before.

  • If the application relies on globally-scoped User IDs to correlate the user across different Facebook application registrations, it will have to make adjustments and use Facebook’s Business Mapping API to do the same.

Recommendations

If you find that there is impact to your Facebook-enabled ACS applications, here is a non-exhaustive list of recommendations. Not all of these may be applicable to you. Refer to the Facebook Platform Upgrade Guide for the complete list.

• Make sure that you don’t have any dependencies on deprecated application permissions.

• Submit extended application permissions for Facebook’s Login Review. Alternatively, you can scale back your application to use only ‘basic_profile’, ‘email’ and ‘user_friends’ application permissions.

• Update your application’s logic to handle declined permissions.

• Update your application’s logic to handle app-scoped User IDs if you have to correlate users across multiple Facebook app registrations. Use Facebook’s Business Mapping API to do this.