Many a times, we come across the need of Single Sing On (SSO) across applications and one suggestion that you may often hear is: let’s use OpenId. But OpenId is not the solution for SSO. In this blog, I am going to explain where OpenId really fits and why it alone doesn’t address SSO.
What is SSO?
When it comes to SSO, idea is to have a notion of centralized trust store among applications that rely on single user identity. As far as SSO is concerned, there are two aspects attached to it:
- A single user identity so that user need not have one id per application/site
- underlying application’s authentication mechanism to have a notion of trust store who can tell that whether specified user is authenticated or not
Understand OpenId
OpenId’s goal is to make authentication for an individual user across web sites hassle free by having all the participating web sites respect supplied loginId for authentication and no need for user to deal with multiple loginIds. This loginId we call openId. This id is nothing but one of your loginIds from a service provider. For ex: if you have a yahoo account with id porwalrk then you can request yahoo to enable the same as an openId and in that case you will get me.yahoo.com/porwalrk as your openId. Similarly, you can have wordpress account or google account or any other account serve as openId as long as each of these service providers have openId service avaiabel at their end.
Now when you access a web sites that is openId 2.0 enabled, you simply supply openId service provider name (like yahoo.com) and user is directed to openId service provider site where actual authentication takes place. On successful authetnication, user is redirected back to original page that required user to authenticate first. I am not getting into details of OpenId protocol that talks about what parameters to send to openId service provider, what to expect back to check for authentication and how to ensure communication is secure.
Before openId 2.0, openId enabled websites required you to supply your openId (which is bit confusing for normal users). The authentication service for this web site (which is based on OpenId authentication strategy) will use supplied openId to talk to openId provider by sending HTTP GET request (i.e. in our use case say you supply me.yahoo.com/porwalrk, hence a request will be sent to http://me.yahoo.com/porwalrk) and in response it will know the openId service location. Now, user will be redirected to openId service location. Now everything is same as what I mentioned for openId 2.0.
In summary, you can use your single account (loginId) to authenticate across web sites as long as they support OpenId based authentication mechanism.
OpenID and SSO alignment
Let’s recall two points we mentioned for SSO. OpenId is just addressing above mentioned point #1. Its not addressing #2 and here is the reason:
As per openId protocol, an application (i.e. its security layer) will ask the user to supply his/her openId and then underlying authentication mechanism will talk to openId server to authenticate the user. Now if this user, visits another openId supported site (say site B) then for true SSO to work, site B should not ask for user’s openId again. Is this possible ? For this to work, there has to be some sharing of information between site A (site where user first logged in with openId) and site B so that openId is known to site B. Normally one uses cookie to share specific information. Since site A and site B belong to different domains there is no way cookies can be shared.
With this analysis, one can make out that openId is just an authetnication mechanism that can rely on single userId (or loginid) and it can be plugged as the authentication strategy within underlying SSO implementation. OpenId should not be confused with true Single Sing On.
Popularity: 56% [?]
March 15th, 2010 at 12:57 pm
Most of the Open-Id services (like https://www.myopenid.com/), does provide a way to remember the authorization given by a user to a site which requires sign-up. It’s only one time effort by the user to register with a valid open-id credentials. Once done, the Open-Id service provider gives an option to the user to remember the registered sites. Later user can even change the access given to the sites he’d visited.
Hence SSO(Single Sign On) is achieved through Open-Id is my statement.
Sukumar