Like many people, I have a WordPress blog, and I ask my readers to identify themselves when they post comments by authorizing WordPress to access their Facebook or Twitter profiles. This helps me filter out anonymous trolls and spammers.
But it is an option not all users appreciate. Twitter user @herminones reached out to me, saying:
Oleg, I would have liked to comment on your most recent blog but for the pre-requisite Wordpress Faustian contract
The option to rely on Facebook or Twitter is not unique to WordPress. Authentication, authorization and password management are some of the key APIs of any useful application. As a result, many apps authenticate via Facebook, Twitter, or another third-party identity provider.
Relying on the social media giants helps both users and application developers. Users don't need to create yet another account and remember yet another set of credentials (my 1Password vault already has 176 entries in it). Application developers can skip implementing authentication, identity and password management.
However, relying on a third-party identity service such as Facebook or Twitter also has its downsides. The application developer must make an assumption that the user has an account with those systems. The developer also must take it for granted that the third-party system is stable and reliable.
This isn't always the case -- in April 2009, Twitter OAuth was temporarily disabled. It took 48 hours for it to come back online. Meanwhile, dozens of third-party apps did not work. Thousands of users could not use the apps they paid for. What made matters worse was Twitter's lack of communication with the application developers.
In another example, consider the March 2015 Boomerang outage:
Hey folks - Google had an OAuth outage this morning that blocked Boomerang from working for about 1 hr. We’re working through your emails!
- Boomerang (@baydin) March 5, 2015
The app developers must also assume that whatever third-party identity provider they choose will continue to be used and trusted by users in the future. Andy LeMay, senior experience design lead at Adobe, wrote on Quora:
One thing to keep in mind is that when you rely on a third-party system in such a way, you're also making the assumptions that the user has an account with that system, that the system is stable and trustable, and that the system will be relevant and used as much or more so than your own site into the future.
(if you saw a "Log-in with Myspace" badge on a site today, what would you think?)
One possibly alternative is some central identity provider allowing the users to maintain a single set of credentials. After all, my phone company knows who I am and so does my broadband provider. But this idea would place the responsibility for security onto entities that historically are untrustworthy. It would also limit the choice and create a single point of failure for the entire Internet.
There is a happy medium, however. OpenID Connect 1.0 is emerging as an identity provider protocol based on OAuth 2.0. As the OpenID Connect FAQ explains:
OpenID Connect lets developers authenticate their users across websites and apps without having to own and manage password files. For the app builder, it provides a secure, verifiable answer to the question: "What is the identity of the person currently using the browser or native app that is connected to me?"
OpenID is backed by enterprise technology companies. Popular social media services, including WordPress, already act as OpenID providers. Developers and power users can also roll their own.
Even with OpenID, it is important to let users log on and use the app even if the identity provider is down. The prudent choice is to offer traditional password-based authentication alongside the OpenID login.