OpenID as a Single Sign On option??

Question

I'm just looking for different opinions. Do you consider OpenID a good "Single Sign On" solution?

The way it works seems to be a little bit confusing for an average user and there could be problems related to "putting all your eggs in the same basket".

Anyway, have anyone tried to implement his own OpenId solution within the context of an Intranet where there are many different applications (Wordpress, Elgg, Media Wiki, ..)??

I consider it could be a great solution to solve the "Digital Identity" problem but I dont know if it will work with the "login once and surf the Intranet" problem.

Opinions? Thanks in advanced.

Answer 1

I think OpenID is far too confusing and clunky to force on any user, and I'm not even convinced it's solving an authentic problem. Having to register on each site I use has never struck me as a major issue. Particularly as it doesn't especially solve that problem; when I linked my OpenID to StackOverflow I had to fill out extra details anyway. It might as well have had a regular registration process for all the difference it makes.

Answer 2

Well.. I'd have liked a simple login-pwd combo (that I'd breeze thru with Passwordmaker.org). However being a developer, I can understand that they didnt want to reinvent the login wheel again...

OpenID:

I enter my blog url => Google sign in => I'm in.

It's an extra level.. but it's OK.

Answer 3

Actually, in the case of StackOverflow, a separate account would have saved me a lot of trouble. I decided to use my WordPress.com OpenID, since that's where I'm hosting my blog, but it turned out that WordPress.com have serious problems with their OpenID service, and most of the time I am not able to log on to StackOverflow at all. Of course, I can use a different OpenID provider to log on with, but then I will have a different identity on the site.

I guess you could say WordPress.com is to blame for this, but the problem reimains the same. By using OpenID you are depending on another site's service to function. Any problems on the third party's site will in effect also disable your site.

As an alternative solution i tried signing in with my Yahoo OpenID, but then I got some random string as the user name, and as DrPizza already pointed out, I would have to edit my personal details anyway.

OpenID is a nice idea, but it's still not something I would rely on with the current state of things.

Answer 4

It took me a while to understand OpenID (so many providers!) but I really like the concept. Tie it in with Gravatar and rewriting your profile is much more painless - perhaps one or two fields.

The only issues are that you have to trust your OpenID provider - but that's not really what I'd call a problem, more like common sense.

Edit: People having problems with OpenID providers should consider setting up a new one. My provider is myopenid.com and I've had no problems. You can setup multiple personas (like profiles) so I have one for blog comments, one for technology sites like this.

As for having a new SO profile Jeff said something about being able to change your OpenID without losing your profile stats in the future.

Answer 5

At least in the intranet scenario, I think Active Directory (or similar) is still one of the best options.

Answer 6

Also, SSO (as you mentioned) usually implies that I only have to login once (presumably to my workstation) and then from there on, I don't need to sign-in anywhere.

OpenID of course doesn't solve that problem. For example, if I use OpenID to sign in to StackOverflow, it doesn't mean I don't need to sign in to another website again using the same openID.

Answer 7

I have to say that I absolutely agree with the statements on it being too difficult for the "average" Internet user. I think that OpenID could still be considered "new", even though the original proposal was back in 2005. More high traffic sites are taking it up as just an option for creating an account, rather than requiring users to have an OpenID present.

In my opinion, as long as normal username/password account creation is offered alongside OpenID, average Internet users will naturally begin to try and eventually stick with using OpenID.

The authentication issues apply just as much to OpenID as registering on any website. You put your trust in the website with your password (assuming you do not use a password storage program) so that shouldn't be used against OpenID.

All that aside, the standardization of account creation is absolutely cream gravy to a web developer. I'd just love to not even have to worry about the normal creation process, and rather just drop in an OpenID library and reference it to the database.

Answer 8

At least in the intranet scenario, I think Active Directory (or similar) is still one of the best options.

Yep, in any case, Active Directory is behind the curtains of the OpenId Server Provider.

In order to develop a SSO solution within an Intranet there are commercial options such as Access Manager (former IChain)+Active Directory but I dont know if theres an open solution apart from "Own OpenId Server"+"Something cool yet to develop"+LDAP.

Answer 9

OpenID of course doesn't solve that problem. For example, if I use OpenID to sign in to StackOverflow, it doesn't mean I don't need to sign in to another website again using the same openID. -- tj9991

It can mean that, though. If your sign-on on the OpenID site is rememberd (for example, through cookies), you would effectively only need to sign on once per browser session (or once per week, once per month...) for all OpenID sites you visit.

Browser support and an API could even do away with the password prompt and the page redirect. Great idea!

Answer 10

It's not such a usability problem on stack overflow since all the users are programmers anyway, but i can't think of many other sites that could get away with it.

I think openID will improve over time though and once all the sites using it start implementing all the features (like auto-filling the about me stuff) it'll be more worthwhile.

Answer 11

There is one tiny problem with OpenID.

Seamlessly logging in with OpenID requires automatic (unverified) redirection between domains.

That makes the OpenID server a 3rd party. This can cause cookies for the OpenID server to be rejected if you turn off 3rd party cookies and your browser strictly follows the Unverifiable Transactions rule in 3.3.6 of RFC2965.

An example of this is Opera. If you turn off 3rd party cookies (by setting the global to "Accept only cookies from the site I visit"), you can't log in with OpenID because the server script you submit to automatically (without your interaction to approve it) redirects you to the OpenID server and the OpenID server does the same to get you back.

But, you get lucky in Firefox, IE and Safari with their corresponding blocking of 3rd party cookies because they violate RFC2965 in multiple situations.

Having to use OpenID in this case does a disservice to more compliant clients.

As a workaround, in Opera, besides accepting all cookeis, you can goto tools -> preferences -> advanced -> Network and turn off Automatic Redirection. Then, you'll be able to verify and click each link you're redirected to and the cookies won't be rejected because the transactions are verified.

It should also work if you keep Automatic Redirection on and both servers generate a page with a link for you to click on so you can verify the transaction. But, there can't be any automatic redirects anywhere.

Logging in with just a username and password where you're only dealing with first party cookies would be much better in this case.

OpenID is still cool though and I guess Opera just needs an option to allow unverifiable transactions between SO and your OpenID server so that you can use "Accept only cookies from the site I visit" here.

Answer 12

I'm pretty ambivalent on OpenID. One the one hand, it addresses the 'identity provider discovery problem' (how the relying party site figures out where to send the user to authenticate). On the other hand, URLs are tremendously clunky to the average user.

I see OpenID as it currently stands as being a useful stop on the road to a solution for Web identity, but certainly not the ultimate destination.

Specifically addressing your intranet question, OpenID is probably not the right answer. As I mentioned above, OpenID buys you the ability to locate the identity provider, at the cost of typing in that URL at every relying party. If you're going to be authenticating all your users at some internal identity provider, and only accepting users from that identity provider, OpenID really doesn't gain you much.

I would look at a system such as CAS or OpenSSO, either of which will redirect users to the login page without any need to enter a URL. I recently blogged about a company that rolled out OpenSSO to 40 intranet applications for 3000 users in just 4 months, with apps on IIS 6.0, Apache, JBoss and Tomcat.

Answer 13

OpenID implementations require a lot of effort and thought to be successful, and even then, you can be thwarted by bad identity providers (for example Yahoo). OpenID can work very well if you've worked out the user experience issues, but a bad implementation is just horribly difficult for most users to work out. In my opinion, the biggest problem with OpenID is that people tried to solve the issue with user awareness. They would have been better off simply giving a list of OpenID providers, and having the users click the one they wanted to use. This sometimes requires knowledge of how a provider has implemented OpenID if they don't support version 2.0 of the spec, but gives a much better overall experience for the end user.