It seems that all the talk around F8 was focused on Anonymous login. While this is an interesting feature, it is just one of the many changes coming to Facebook Login with Graph 2.0.
It seems that all the talk around F8 was focused on Anonymous login. While this is an interesting feature, it is just one of the many changes coming to Facebook Login with Graph 2.0.
Anonymous Login will only be available if the website or mobile app decides to offer it as a separate button to Facebook Connect. We actually don’t think many will implement it.
The most impactful change is that the standard static Facebook permission dialog is now in control of the user. Permissions are now optional for people using your app. The Login Dialog will now allow the user to choose what info they share with your app. People can disable what they share on a permission-by-permission basis. Anonymous login will now simply yield a authentication token without any permissions.
Hacker note: Technically this has always been possible with the web based auth dialog by simply deleting permissions from the scope list in the URL 🙂
While its nothing new, Facebook has added a convenient UI for everyone to control what data they share.
So, for example, if a user is presented BELL permissions, they could now opt out of any specific permission, say “E” (email address). The best practice for all social authentication is to pre-populate registration fields from the social data, that way if a field is required for the app, you can enforce this upon final form submission.
What Does This Mean for Developers?
Since technically this has always been possible, you should have already been checking the granted permission in the user’s token before permitting the use of a permission gated feature.
To handle this case you can ask for additional permissions, but unlike before you cannot re-request an explicitly declined permission. You must use a new option in the Login Dialog called auth_type: rerequest
In keeping with this theme of protecting the user’s data, Facebook has declared that public_profile, email and user_friends as a basic set of default approved permissions. Any additional permission will require review of your app by the Facebook team. This likely means that Facebook will require a valid explanation of why you need the data behind each permission.
Facebook has also removed many permissions in 2.0 to protect users and their friends’ privacy by also removing the all of the friends_* permissions.
Friend Lists Are Now Title Only
The user friend list returned via an app token will now only contain the friends who have also authorized this app and not the entire set. In keeping with the user controlled privacy settings Facebook is removing the ability for a friend to divulge your data.
User IDs Are Now App Scoped
The ID retrieved from the auth token is now specific to that app. You will no longer be able to retrieve the globally unique user ID like before.
Facebook has provided a federated user ID solution if you own and operate multiple apps, via the new Business Mapping API. This allows for the mapping of the same Facebook user ID across your apps.
App-scoped IDs will invalidate all Facebook data scraping aggregation services. Since all of their data is keyed on the user ID, first party data will now be the new standard.
For platforms like Umbel, this is great news. We have always taken this siloed approach to our client’s data in order to preserve and leverage their data rights.
