Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why should I use OpenID?
31 points by pierrefar on March 31, 2008 | hide | past | favorite | 30 comments
I know this is going to be controversial and I know I may have missed something, but here goes...

As a website owner, why should I allow OpenID logins on my site? I see one major disadvantage: I don't have any contact info for my users. This breaks the primary link between me and my users.

I can see OpenID being used for many scenarios, but I don't think it's the ultimate cure of login cancer it's hyped up to be.

Again, I'm all ears to learning something new here.

Thanks, Pierre




OpenID is not a replacement for your users table. The first time someone logs in with an OpenID you haven't seen before, there's nothing to stop you from asking them for their e-mail address (you can even send them a challenge e-mail if you want to be sure). All OpenID really does is provides your users with an alternative to setting up Yet Another username and password just for your site. It also lets people opt-in to correlate their accounts across multiple services, which is useful for both you and for them.

If OpenID meant giving up the user database (the crown jewels of any site) it wouldn't have a chance of being adopted by anyone.


So why ask the user to enter an OpenID login and then follow up with an email address? An analogy: you're filling out a form and you think you're done because the front page is short and sweet. Then Mr Evil Banker Man tells you, actually, you missed the back side and that's long and convoluted.

That's happened to me and I always felt betrayed, as if being led into something naughty and the person doing the leading is hiding something.

In short, there is something stopping me from asking for the email address, and that's usability and trust building.


To summarize/add:

You not only keep the users email address but you make it easier for users to give you there email address.

Check out disqus.com or plaxo.com's integration of OpenID, Plaxo in particular gets lots and lots of user contact info for users that use OpenID.


What percentage of non-techies has even heard of OpenID?

What is important to the computer world is different from what most of the rest of the world values.

For me, the ultimate answer would depend on how computer-savvy my intended audience is and how much extra effort is necessary to support it.


You could have said the exact same thing about, say, the Internet 20 years ago.

I'm not claiming OpenID is as important as the internet, but just because average people don't know about it doesn't mean its not important or won't be important in the future.


There's a way to fix this, but it isn't widely known yet. Using browser history sniffing[1] you can determine which popular IDP the user uses (let's say AOL) and then you can customize your login box to say "log in using your AOL screen name". So you're doing OpenID, but the user doesn't have to know what OpenID is. This is a little cumbersome to implement; maybe somebody will write a JS library to do it.

[1] which will probably be removed from browsers at some point, but let's exploit it while it lasts


Well it is not too difficult to implement and it can speed up the registration flow for new users, which should always be a good thing.

OpenID is still getting better though. Yahoo! just became an OpenID provider which should help it catch on. And the ClickPass guys have built a great tool on top of it as well. So it looks right now like OpenID will survive and become better in time and perhaps achieve the goal of replacing the registration flow.

So while you say it is not the cure right now, I think that if you give it enough time it possibly could become one.


As a website owner, OpenID nets your site security. Most people reuse the same small set of usernames and passwords. A not-so-small number of sites store cleartext passwords; they can even mail it back to you. Regardless how well you execute security, a breach at any of these sites compromises security across many user accounts across many sites.

Several weeks ago a Web 2.0 company launched a Gmail backup app that asked for addresses and passwords, which at least 1777 unwitting folks provided. In addition to backing up Gmail as expected, the app also socked away the address and password combo. When the scheme was exposed, the company said debugging code inadvertently made it to production. http://codinghorror.com/blog/archives/001072.html

I can see scenarios where the government may be the least of our worries. Much more likely are significant others' jealous exes who are also system administrators, and other real or potential enemies. The sooner we move away from passwords and other shared-secret systems, the safer we'll be.


Alternative question: why shouldn't I use OpenID?

What are the common concerns, and which are valid/invalid?


As far as I can tell, the biggest concern is that OpenID makes phishing easier and more valuable. When the same user ID and password open all your accounts, one mistake compromises everything. Let's say clickpass gets huge, and someone forges a malicious clickpass-lookalike widget. They spread it around the net. Any password they steal gets them in to all clickpass-enabled accounts.


The weakness of the above argument: Why would site-owners install an untrusted Clickpass widget spread around the net but not from Clickpass itself?

I can see how some users might fail to recognize a Clickpass or OpenID url and give their login credentials to a fraudulent site, but no worse than password management, OpenID requires folks be on guard against phishing.


It's the same problem as current passwords, but with higher consequences for those who don't use the same userid and password across sites.


I think the only real answer to that is if you think OpenID is likely to confuse users during signup and therefore you loose users. I think even though its early the increase of signups is likely to be greater than the loss of users through confusion. Especially if implemented well using Clickpass ;-)

Also another answer is that it is currently not completely trivial to implement, so if you don't think the benefit outweigh the time to implement than you wouldn't. Hopefully we will help fix that soon as well.


Here's my list, in no particular order:

- OpenID is a mystery to anyone who isn't a geek, and also to many geeks.

- The extent of OpenID's positive (or negative) influence on user signup rates, or anything else, is unproven. The technology brings no clear benefit on day zero. Nobody can tell you what the return on investment is.

- OpenID used to be about the promise of one-textfield signup. But, oops, if you want to speak to the user again you also have to ask for an email: two textfields. If you want to make sure the email is valid you need to mail out a confirmation link. At which point do the advantages of OpenID wash out? There is no usability data.

- There are security questions, but few answers. The number of free variables, and the fact that nobody bothers to attack a system with no significant userbase, makes these issues hard to pin down. It is certainly true that a less-than-perfectly-competent provider can render OpenID very insecure.

- OpenID, as proposed, introduces a dependency between your code and the code running on hundreds of providers scattered across the net. You have no control over these providers, they have no legal obligation to you, and your site's uptime is completely dependent on their uptime.

- There is no standard OpenID provider implementation, so there is no way to know at any time which of your users' identities might have been compromised by insecure or unpatched software. There is no way to run automated tests between your code and that of every provider. If you do find a bug in a third-party-provider's code, you have to beg them to fix it, or beg a subset of your users to switch providers.

Yeah, I know, there's a standard. There are standards for email, too. Find a forty-year-old email admin and ask them how easy it was to make all the mail servers on the net conform to those standards.

- Your users probably don't understand OpenID very well, so when they have login troubles they will complain to you. You can't fix many of these problems, but they will not know that. Your $20-an-hour tech support person may not know, either: is your site at fault, or the provider's site? Even your $100-an-hour back-end programmer may have to spend twenty minutes figuring it out. Then, if it's the provider's fault, that fact has to work its way back up the support chain to the user, who will be confused and unhappy. Multiply the cost of such an incident by the number of confused users. Estimate the number of users who will be confused. By OpenID. Better go looking for another round of investment.

- Finally, an OpenID provider owns a subset of your users -- it may not own them outright, if you've been shrewd enough to capture email addresses, but it certainly owns them as much as you do. The provider can redirect the users, show targeted ads to them on the login page, allow your competitors to bid on them. It can do all this with perfect knowledge of when, where, and how often your users log in to your site and most of the other sites on the net.

---

Now, a lot of these problems go away if you give up on the "Open" part of OpenID and restrict your users to a certain subset of "trusted" providers. Like, say, Clickpass. You can sleep well at night knowing that the Clickpass folks are smart, that they fix their bugs and answer their mail, that if something goes wrong for a user there's only two places the bug can be (your site or Clickpass), that their security has been audited, that they have a decent privacy policy, and that they've done their best to make it all so simple that a monkey can understand it. Then, after Clickpass has become successful, they'll be bought by Microsoft, renamed to "Passport II: Electric Boogaloo", and everyone will live happily ever after.


Well said. This is why I think if OpenID is to survive, the provider must be the end user's ISP.

- They already have a relationship with the user, mitigating trust and tech support issues to some degree.

- They already have the power to redirect webpages, spam the user, and find out what sites they are visiting, so you aren't giving them any more power than they have.


It shouldn't end at the users ISP. This ties the user to a using a certain ISP, or they have to give up their online identity.


In my case, we're a startup with finite time. Adding OpenID support (AFAICT) would take more than 3 lines of code, and very few (if any) of our target audience has an OpenID. Therefore, today, I think it's not a good use of our time.

If/when this equation changes (i.e., everybody has an OpenID, or it's trivial to support), I'd be happy to add it.


The reliably thoughtful Chris Messina just posted on the benefits and costs of OpenID, partly in response to a decision by linkmarking site http://Ma.gnolia.com to stop accepting traditional address and password registrations in favor of OpenID only. http://FactoryJoe.com/blog/2008/03/30/magnolia-moves-to-open...

In the cat and mouse game between site owners and spammers, data on recent Ma.gnolia registrations showed an overwhelming number of spammers have begun using automated tools to proxy Captcha and create traditional address and password logins. For now, OpenID encumbers them by requiring presumably more valuable credentials.


It would've been nice if OpenID provided a way for Web sites to contact users without knowing their email address. This way, the Web site owner will not to put up an annoying page asking for an email address, and the user has control over who's allowed to contact them through their settings with their OpenID provider.

Facebook is hopeing to be such provider and they're giving these nice features. There are a few Web sites that allow you to login to using your Facebook cridentials, and by doing so they can email you without knowing your email address. And, Facebook allows you to optout at any time and they also measure how many people opt out and put a cap on the offending Web sites if they start to spam people. It's a nice system, except for the vendor lockin part.


As a web site owner, I've always seen openid as a nice thing to have. It was #40 on my list. Then clickpass showed up and it moved to #3. Last week I implemented it. I integrate with disqus. Log in to either disqus or ourdoings via clickpass and logging into the other site is just 1 click. It's very slick. If people do adopt clickpass they'll be reminded that I'm one of "your sites" and come back.


To re-emphasize/clarify previous statements, OpenID doesn't require visitors to know about OpenID. A website can offer a registration/login process that requires nothing more than the visitor's AIM screen name, or livejournal account. (See example http://nshrine.com/u/registerhere.html )

This not only eases the yet-another-name-and-password problem, but it also allows services complimentary to existing services to ease information sharing. For instance, OpenSocial functionality will be a breeze if accounts are already using an OpenSocial provider's OpenID.


It's good business to be friendly to your users. Also, for people who already use OpenID, having OpenID on your site lowers the barrier for entry.


for people who already use OpenID

That's one thing I never got about OpenID and its ilk, though. "We'll fix the way logins work! Just sign up for one more thing and then sites that support this will be accessible." Why is this the cure for sign-ups? Yet one more service to fill out some credentials for when sites do not universally accept it? If the latter part were true, then sure, but in the meantime I don't really see the point.

I am ignorant of the major benefits of OpenID, so if anyone could enlighten me, I'd be happy.

Edit: this post helps http://news.ycombinator.com/item?id=151376


America Online + AIM, Yahoo, Flickr, Livejournal, Vox, Typepad/key, Google, and enough widely-used sites, plus Drupal, Wordpress, and other widely-used platforms provide OpenID that very few users would need to create yet another login/password. Those already with many logins would likely already have multiple identity providers from which to choose. Those with few logins would presumably have less of an issue.

See http://wiki.openid.net/OpenIDServers for a much larger (but nowhere near comprehensive) list of providers.


Well, when two sites offer the same features but one offers OpenID and one doesn't, I'll be a little more wooed by the one /with/ OpenID. But then again, maybe I'm not your target audience. ;)

My use of Ma.gnolia over Del.icio.us illustrates this.

I guess the main idea is that it can't hurt to implement OpenID, it can only help your service. You can still ask your users for all of the data you ask for during a normal registrarion, but /you don't have to/.


For those who have already added OpenID support, or something like Clickpass - what is the adoption rate like? How many people use it versus the traditional login?

I would be surprised if it's as high as 10% even for a tech-savvy site like News.YC, but I'm not basing that on any facts. Am I way off?


Given all the well-thought-out objections on this thread, I've decided to back out of the OpenID support I recently implemented. Details here:

http://ourdoings.com/2008-04-01


You would just have to assess your target audience and decide whether the cost of developing support for OpenID are outweighed by the benefits of allowing a portion of your users the convenience.

I see little reason to implement it if your most of your users will be unaware of it. On the other hand though, having the support for it (and similar providers) may help you attract those users who do use them. If you do implement support though, make sure it doesn't obfuscate your registration and login processes.


You shouldn't.


Good question! I mean that in the sense that I also have wondered about what I should do.

From what I've read and researched (based on the answers here), Clickpass is the best way to go.

It's also got PG's support, so it can't be all bad. :-)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: