I recently worked on a project where users were required to have an account with the web site but they could also connect that account to their Facebook or Twitter accounts and log in with any of those three.
It was a rails project, so I got to have my first taste of using the Omniauth and Devise gems together. I’m in the early stages of creating a sample for my portfolio using PHP, and I wanted to take a time out to discuss something I found very interesting.
It’s the philosophies that FB and Twitter have about identity. It didn’t even occur to me that there would be a difference until I started reading through the full terms and developer policies for FB. I had just set up a ‘work’ account and was having trouble with the identify verification step that they require before you can develop FB apps, so I actually read the entirety of the terms and discovered that what I was doing was in violation of them. The philosophy of FB is bascially ‘one account, one identity’ and duplicate accounts is specifically mentioned as a violation. I’m always reluctant to tie my FB account to work in any way (I am not FB friends with anyone from the last office I worked in), but I thought, hey, others are doing it, so it can’t be that bad. And it’s not. In fact, because of this philosophy, FB has the benefit of a fleshed out user-role system so that people can be admins, devs, testers, and a couple different types of special users.
The Twitter developer terms, on the other hand, are more focused on playing nice with their users and Twitter branding. In terms of identity, I believe they just expect you to have multiple accounts for multiple purposes. I imagine one example is that you are a poet and the same people who love your 140-limit haikus do not care one bit about your political re-tweets (especially this year!). Or, you have a company Twitter account that everyone on staff has access to, in addition to whatever personal accounts you all have. So this means that your Twitter app is tied to your Twitter account, and it is not very easy to transfer that ownership.
In both cases, though, it is very easy to set up. I quickly learned that using http://localhost or http://127.0.0.1 for the URL settings works while your app is under development. The Omniauth gem for Rails made it very easy to paste in the secret keys and get round-trip authentication working in minutes. Tying them together and to your system is a little tougher, and every method has pro’s and con’s. In this specific system, since the authentications must be tied to a local account, I found nice method where the only cleanup item would be a background job that periodically purges the temporary authentications for users who log in with FB or Twitter and then decide not to go through with completing the sign-up process.
All in all, I had a pleasant experience learning about FB and Twitter authentication and am looking forward to working with them again.