I’ve been paying close attention to the proliferation of blog commenting systems that enable authentication through third-party sites (mostly Twitter and Facebook, but there are others).
There are two competing tensions at work here: user convenience versus identity verification.
First, the site provider wants to make it as easy as possible for users to identify themselves. Third-party authentication enables users to authenticate through another site (like Twitter or Facebook) without having to fill out yet another form and establish a password at every site in the universe. If the site owner can make this process more convenient for me, it’s more likely that I’ll post comments.
But at the same time, site owners want to attach the comment to some real (or, at least virtual) identity. This is done to facilitate conversation, but it’s primarily an anti-spam and anti-troll tactic. And that’s totally reasonable.
The balance between user convenience and identity verification is struck by enabling the user to authenticate themselves through one or more third-party web sites that already store identity information for that user. But those third-party sites aren’t just identity-verification machines. They also are functional applications which store information on users’ social connection. When I authenticate on someone’s blog using Twitter or Facebook, I also have the option (but, importantly, not the requirement) to give that blog permissions to access my Twitter or Facebook account.
And therein lies the problem. Many blog comment systems are exposing users to security and privacy vulnerabilities because they are asking for too many permissions. Here’s a common example:
I nearly always attempt to log in via Twitter if I can, since I don’t trust Facebook (or its app developers) anymore. With a Twitter-enabled application, a developer has a few options in terms of what permissions you can request from the user: read tweets from the user’s timeline, see who you follow, follow new people, update your profile, and post tweets on your behalf.
None of these permissions are necessary to validate your identity to a blog comment system. There is no reason why Disqus should be allowed to edit my Twitter profile. The WordPress.com commenting system has no need to tweet on my behalf. And so on.
Since I worked on federated authentication initiatives at both eBay and Yahoo (and I was a consultant to Twitter on their developer portal rollout), I pay a lot of attention to this stuff. And I understand the technical implications of it pretty well. But I’m sure that most blog commenters do not. And judging by the number of VCs I follow on Twitter whose accounts have been turned into spambots, I am sure that even “sophisticated” users aren’t thinking this through.
That means it’s up to site providers and developers of commenting systems to protect their users. If you have a blog with a comment system that uses authentication through another site, you should check that system by logging in via Twitter and Facebook as a commenter to see what permissions your comment system requests. If it’s asking for any kind of write access to a user’s account, then it’s asking for too many permissions. This means that if a security vulnerability is discovered in your site in the future (and it will be!), you will be complicit in turning all of your users into social network spambots.
If your blog comment system doesn’t let you control the permissions it requests, you should dump that system and get one that does.
Federated authentication providers enable application developers to request granular permissions for a reason. Application developers must take advantage of that.