Reading on Techcrunch that Facebook was going to let people log in with OpenID left me with a mixed feeling. On one hand, it’s a shame that most services claimed to support OpenID while only offering an ID, but not letting people use outside IDs to log in. On the other hand, it’s going to be a big headache for API calls.
Think about it: with OpenID, there are 3 actors in place. The user, the OpenID provider, and the web service. So John@myspace will go to Facebook, Facebook will call MySpace to make sure that John is really that John, MySpace answers and we’re done. With a classical API call, again, 3 actors. The user, the web service, and the third party application. John goes to the RockYou page, RockYou calls Facebook to get a token to access John’s data, and we’re done.
Now, think about an API call through OpenID. 4 actors: the user, the OpenID provider, the web service and the third party application. The OpenAuth fiasco showed how hard it was to do a secure communication between 3 actors, now we’ll get to 4?
Of course, people are going to figure out technical ways to do that. I’m sure Facebook wouldn’t support OpenID if it would break their app ecosystem. But how complex is it going to be? Do the user logs in the OpenID provider, then confirms on the web service, to finally go to the web service? Talk about a simple process.
I just hope they have a good reason for supporting OpenID, not just “it would be cool to have a single login for all websites”.
You forgot to mention Passport, that was supposed to give web site owners a trusted, deported authentication process (but centralized in this case). The Passport APIs are fully integrated in .NET framework (just a line in the configuration file to use it), but I’ve never seen a non Microsoft site using Passport yet.
That’s right! I forgot about this Passport thing.
It’s interesting however to see that Passport-like centralized systems exist today, with more success: Facebook Connect, Google Auth (with App Engine).