We are building a service. This service needs to relate to end-users. The users will mostly interact with our service through third party sites. The users, the aforementioned third party sites and others will probably refer to us as the third party, but I allow myself to be selfish for now. Anyway, the bottom line is that we need authentication for users in our own service and also authorization of third party sites to allow them to access a user’s data only with the permission of the user.
Naturally, when one has a need for authentication, one looks at existing solutions. The classic implement yourself is of course an option and may I add, a strategy that is all the rage with the NIH (Not Invented Here) crowd. I’m not too fond of NIH, but I am a big fan of KISS (Keep It Simple, Stupid). While those principles aren’t direct opposites, simplicity mostly dictates using an existing solution. OpenID, Facebook Connect and Sign in with Twitter exist and are all easy to use through existing libraries.
OpenID is cool. Unfortunately, we expect that most of our users do not have active OpenID accounts from day one. Forcing our users to sign up for an OpenID account in order to register for our service doesn’t exactly seem like a good idea. We do expect that a large percentage of our users will have Facebook accounts, but we are not developing a social networking service so it’s a bit weird to rely on Facebook Connect alone.
Since many of our users will have Facebook accounts, we will probably allow users to register with Facebook Connect. OpenID is however a more neutral system, so we will also support that. We need a simple way for users to register locally without having to register for an additional service as well. The solution to this is to provide OpenID ourselves.
The situation for authorization is a bit more straightforward. OAuth is a very simple and straightforward scheme that seems like a good match for our needs. Other solutions originally developed for single sign-on would work as well, but OAuth is designed for this and very simple to implement as well. Whether people are used to OAuth or not doesn’t really matter since it will only ask them to allow a site to access their data.
To sum up, we will support Facebook Connect, Sign in with Twitter and OpenID. To avoid introducing a local authentication scheme, we will provide OpenID ourselves and make registration simple. For authorization, we will go with OAuth.
Out of Sync 